Remarks 

The present Office Action incorrectly matches descriptions in the prior art with the presented claims. 
Applicant respectfully points out that the present invention covers user interface for access control. It 
is a combination of user interface and access control. Applicant believes that it is necessary to 
understand that traditionally, user interfaces and access controls have been in separate Art Units, and 
have not been combined as in the present disclosure. Art Unit 2174 appears to be for Graphical User 
Interface and Document Processing. Those of ordinary skill in the art of user interface have not had 
skill in access control, and vice versa. Specific arguments are made within context below. 

Previous amendments: 

Applicant withdraws amendments to the specification submitted 2009-03-18, 2009-1 1-09, 2010-06-21, 
and the substitute specification submitted 201 1-02-02, all of which have not been entered. 

To clarify in case there would be any questions about the identification of these amendments, Applicant 
respectfully points out while the Office Action mailed 2012-02-09 mentions a number of amendments 
on specific dates including an amendment supposedly submitted 2009-06-10, in fact there has NOT 
been an amendment submitted 2009-06-10. The record shows amendments to the specification (and 
rejections respectively): Essentially the same paragraph submitted 2009-03-18 (not entered 2009-06- 
10); submitted 2009-1 1-09 (not entered 2010-01-19); submitted 2010-06-21 (not entered 2010-09-02); 
and lastly a substitute specification submitted 201 1-02-02 (not entered 2012-02-09). 

Substitute specification: 

For the purpose of easing consideration of the present application, as provided in 37 CFR 1.125 (b), 
Applicant now files a substitute specification. Marked and unmarked copies of the substitute 
specification are provided as Attachment A and B, respectively. Please replace the specification with 
the attached substitute specification. 

The only changes relative to the immediate prior version of the specification of record are 
unambiguously marked between page 5 line 3 and page 7 line 1 1 . 

No new matter: 

Applicant hereby states that no new matter has been added to the specification. Any additional words 
incorporated into the new specification are merely illustrative examples known to one skilled in the art 
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as of the time the invention was made and therefore are not new matter. For example a PDF document 
has been widely known to be a kind of digital document, one skilled in the art would have recognized a 
PDF document as an example of a digital document, and mentioning a PDF document in the present 
amendment to the specification is to provide clarification for a narrowed claim with scope reduced to a 
PDF document. 

Election: 

In response to the requirement for restriction (paragraphs about election by original presentation) in the 
Office Action mailed 2012 February 9th, applicant provisionally elects to prosecute the claims labeled 
Species 1 (Claims 1-9, 11, 28-34, 36, 38, and 40-51) and hereby cancels the claims labeled Species 2 
and 3 (Claims 52-70) without prejudice. 

Reconsideration of requirement: 

Applicant requests reconsideration and withdrawal of the requirement for restriction (election by 
original presentation), because what in the Office Action mailed 2012 February 9th has been labeled 
"Species 1" actually is the genus, which encompasses the species. 

It is well known in the art of computer science that a "Portable Document Format (PDF) document" is 
a particular type of "visual digital document". 

Analogously, a "visually compound digital text document" (e.g. an HTML document) is a particular 
type of "visual digital document". 

Statutory subject matter: 

The substitute specification specifically defines at page 6 line 27 a "visual display unit" is a hardware 
component. Therefore, recitation of the visual display unit within claims recites a hardware 
component. 

One skilled in the art as of the time the invention was made would have known a visual display unit is a 
hardware component. Applicant has never indicated otherwise. 

The Wikipedia entry for "visual display unit" at the time of this writing redirects to "computer 
monitor". 
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Claim formatting: 

Any indentation or other formatting of the claims is intended for clarity, and shall not be considered a 
limitation or in any way affect the construction, which shall solely be based on the words thereof. 

Drawings: 

Figure 40 now has been corrected from a clerical error. One of the adc attributes has been moved from 
Figure 40 content line 6 to Figure 40 content line 8, in order to match the rendering of Figure 42. In 
contrast to this error, there have been several correct instances of use of adc attributes in Figures 40 and 
44 and corresponding renderings in Figures 41-43, 45 and 47-49, and the description in the 
specification has been correct. One skilled in the art would have been able to understand the teachings 
presented, based on the correct description and aided by the correct examples. 

Information disclosure statement: 

Applicant files a supplemental information disclosure statement not only but also in order to be sure 
that all of the art of which Applicant has been made aware by the Patent Office is of record, without 
prejudice, for compliance even if Applicant would only consider it marginally relevant; 
also in order to be sure that all of the art of which Applicant has been made aware of by a third party 
prior art search is of record, without prejudice, for compliance even if Applicant would only consider it 
marginally relevant; 

also in order to be sure that all of the art of which Applicant has newly found historical notes by 
Applicant saying it might be relevant is of record, without prejudice, for compliance even if Applicant 
would only consider it marginally relevant for the present claims; 

also to include non-patent literature, some of it prior, some of it educational about access control, and 
some of which may not be prior, some of which may be the earliest version found of a product the even 
earlier history of which, if any, isn't known, 

and some of which may be indicating the problems which the present invention solves still haven't 
been solved by others in the art. 

In response to action item lib: 

Examiner incompletely quotes and presumably so considers Applicant's argument as: Sekiguchi fails to 
disclose 'log information for a single specific predetermined digital document. " Applicant's full 



reply 



page 18 of 38 



10/802,658 



argument has been: "Sekiguchi doesn 't teach the present invention 's carefully defined compiled log 
information for a single specific predetermined document. " 

A good approach to analyzing 35 USC § 103 rejection arguments for the present invention involving 
Sekiguchi should be: First read the present specification, then read the present claims, then read 
Sekiguchi. 

Sekiguchi doesn't teach the present invention's carefully defined compiled log information for a single 
specific predetermined document, let alone showing it in user interface. 

The present invention's carefully defined compiled log information for a single specific predetermined 
document is essential for usability, both for human comprehension and to fit into display space. 

The present invention teaches limiting to showing one document's access information only. Further, 
the present invention teaches visually grouping information per user. 

Sekiguchi doesn't teach user interface for log information, but Sekiguchi figures illustrate the workings 
of an automated "security monitoring apparatus". 

Sekiguchi user interface displays alarms only. Examples of Sekiguchi user interface, rather than 
internal workings, are in Sekiguchi Figs. 15 and 16. In appearance and workings Sekiguchi 
significantly differs from the present invention. Sekiguchi doesn't give an operator the information the 
present invention does, not the same information, let alone in the same context. 

Sekiguchi teaches algorithms searching for patterns. Examination has shown Sekiguchi patterns to be 
different than the present invention's. Patterns being different or not, different than the present 
invention, Sekiguchi doesn't teach showing the same essential information in user interface. 

If Sekiguchi Fig. 9 were relevant as user interface (but it is an engineering illustration of a section of a 
file, log, stream or data) it would be an example of information presented in a way that isn't fit for fast 
and effective work by a non-technical user who is legally responsible for correctly handling access 
control to documents while under pressure to perform more work in less time. 

Just showing log files would be too much information for users. People can't use that. What fraction 
of non-technical professionals would actually read log files? 

Figure 9 of the present disclosure "shows a moment in the user interface of an implementation of the 
present invention. For a given URL 400 the Web browser shows a familiar representation 401 of the 
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document. Adjoining there is an region 410 with a representation of the effective access control 
settings for the document. User Lee 411 has write privilege, as indicated by a green pencil next to the 
user 's id. Group Marketing 412 has read privilege. User Rolf 413 has read privilege. Further 
adjoining there is a comprehensive representation of log information " for the document, one row per 
user showing carefully defined compiled log information including user identity 420, a row's user's 
"most recent write access 430" to the document and a row's user's "most recent read access 440" to 
the document, "for each individual user". 

Skeiguchi doesn't teach the present invention's user interface or comprehensibility of access log 
information for a non-technical user. 

The present invention specifically teaches those, in order to solve an information security, access 
control usability problem. 

If claims 45, 46, 55, 58, and 66 are allowable then all claims that depend are similarly allowable. 
In response to action item 11c: 

Examiner by underlining and by argument indicates incomplete consideration of Applicant's argument. 
Examiner has underlined: The Examiner respectfully submits that Barkley does disclose '[displaying] 
normal size, legibly scaled, unabridged representation of the content of the document ' (col. 8, lines 44- 
65; col. 13, lines 19-60; Figs. 2, 4, and 5; file name and file path are displayed on Role/Group 
Permission view; Fig. 5; file 'ko.acc '). Examiner's argument continues: One of ordinary skill in the 
art would understand that file name and file path are representation of the content of the document. 

A good approach to analyzing 35 USC § 102 and 103 rejection arguments for the present invention 
involving Barkley should be: First read the present specification, then read the present claims, then read 
Barkley. 

Barkley doesn't teach the present invention's carefully defined normal size, legibly scaled, unabridged 
representation of the content of the document , let alone showing it concurrently visible and 
concurrently operable with access control settings . 

Document content in the art and in general is understood as the informational content of a document 
itself, not its metadata. 
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To illustrate the difference: If a directory path would be 

/documents/ 
and a filename would be 

newengine.doc 
then, in contrast, document content could be 

New Design of Internal Computation Engine 

After more than two dozen years of development we have developed mathematical proof that engines can run 
on numerical computation alone. This document is intended to describe how to turn that theory into a 
deliverable product by the end of the decade. 

Before going into details we would like to include a transcription of the Bill of Rights (Constitutional 
Amendments 1-10) of the United States, as found at NARA (National Archives & Records Administration). 

Barkley user interface doesn't show document content. 

To equate filename with document content appears otherworldly. Further pursuing arguments how 
someone could construct this to be true would give a flair of legitimacy to an attempt at redefinition of 
concepts and terms well known in the art. 

Applicant respectfully suggests to focus on mainstream understanding of the art, and to interpret terms 
consistently with mainstream use. 

The present specification explicitly clarifies: A "normal size, legibly scaled, unabridged 
representation of the content of a resource" is what commonly is shown in normal use by a word 
processing application or by a drawing software when the operator views or edits a document. 
Examples of "normal size, legibly scaled, unabridged representation of the content of a resource " are 
display regions 401 and 501 in Figures 9 to 23 and 26. A "normal size, legibly scaled, unabridged 
representation of the content of a resource " is different than a thumbnail of a drawing or a summary of 
a document. 

A filename is even less of a representation of content than a thumbnail or a summary. 
If claims 1, 52, and 63 are allowable then all claims that depend are similarly allowable. 
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In response to action item lid: 

Applicant's arguments against Hildebrand anticipating claims 45 (was 10) and 46 (was 12) are and 
have been manifold, involving at least two topics (quoted from reply submitted 201 1-02-02): 

A rejection based on "Hildebrand teaches a graphical user interface for representing 
access log information... " cannot stand. Apparently since the Office Action mailed 2010 
January 19 action item 22b Examiner has been considering "It is noted, however, that 
Hildebrand does teach a graphic user interface for representing access log information 
(Hildebrand: par. 0201; Fig. SA; access report module 704 reports user's access activities 
[reporting user's access activities is equated as representing access log information]). " 
Thorough inspection has revealed Hildebrand "Access Report Module 704" is in "Client 
Module 702" in "Memory Space 703" in a "Client Machine 700"; Hildebrand "Access 
Report Manager 518 " is in "Server Module 502 " in "Memory Space 503 " in a "Server 
Device 500"; Hildebrand's "Access Report" has a raison d'etre unrelated to displaying log 
information (par. 0018; During the offline access period, an access report manager may 
be activated to record all activities of the user accessing the secured documents. When the 
client machine is once again connected to the AC server, the access activities of the 
secured documents can be reported to the AC server to facilitate the access control 
management and synchronization of the secured documents accessed or created offline.); 
and Hildebrand provides no teaching regarding a graphical user interface for representing 
access log information. 

and (also quoted from reply submitted 201 1-02-02): 

Hildebrand teaches (Fig. 2C.1; par. 0102; illustrates an exemplary structure of a secured 
document 236 including a header 238 and an encrypted portion 239). Claim 45 (was 10), 
however, is directed at a visual display unit, which can be seen by an operator (a user). 
Hildebrand teaches (Fig. 2D; par. 0108; an exemplary graphic user interface). In 
Hildebrand's user interface settings (Fig. 2D; par. 0108; Actions 277 determine how the 
data in the designated place can be accessed) apparently apply the same to all users in 
(Fig. 2D; par. 0108; access list 276). Hildebrand teaches (par. 0135; the system 
administrator sets up hierarchy access levels for various active folders, storage locations, 
users or group of users) not providing user interface to set access control per document. 
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Hildebrand apparently neither teaches user interface for showing or setting specific access 
control settings per user nor per document. 

On the first topic, Examiner in the instant Office Action apparently accepts and doesn't refute 
Applicant's argument "Hildebrand provides no teaching regarding a graphical user interface for 
representing access log information ". 

Regarding the second topic, Hildebrand in par. 0108 discloses the "designated place" is "a folder or a 
repository" and the GUI does "determine how data in the designated place can be accessed" . Fig. 
2D, par. 0108 actions 277 "Default rights for files in this group" apparently are neither indicated to be 
for a specific user (which one specific user would that be?), nor for a specific document within "the 
designated place". In only providing one set of access control settings for a whole folder, Hildebrand 
significantly falls short of the utility provided by the present invention. 

Hildebrand in par. 0135 discloses "For example, as shown in FIG. 5B.1, different users can be 
assigned to different access privileges. User A may be an executive or a branch supervisor who has all 
the access privileges to any secured documents. " It reads "to any secured documents" \ which isn't to 
a specific document. Hence, even if one allows par. 0135 and FIG. 5B.1 to be interpreted as allowing 
the setting of access control settings per user, Hildebrand nevertheless does not teach user interface for 
setting the present application's claimed access control settings for a single specific predetermined 
digital document. 

As a whole, Hildebrand doesn't teach necessary thinking for "a set comprising a plurality of individual 
users " for each user to display whether "the user for the single specific predetermined digital 
document has privilege different than having read privilege ". The present specification does. 

The careful wording of the present claims isn't accidental or mere wordsmithing. To not pay attention 
to what exactly is described in the present specification is to deprive the present claims of their life. 
Analogously, as an extreme example, one would be hard-pressed to tell how an electromagnetic coil in 
a relay is different from a mere thread or wire on a reel if one would not pay attention to the teachings 
of electromagnetism. An electromagnetic relay would have been denied patentability because prior art 
had existed with thread or wire on a reel. With the present invention special attention is required to 
matters of access control. It is in the careful choice of how access control information is processed in 
order to be displayed together with how it is displayed that the present invention is innovating and 
making a useful article. 
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The purpose of the carefully defined mechanisms of the present invention is actual usability. Its 
innovations make per-document access control usable for non-technical professionals who are 
responsible for documents. 

No matter what conclusion one reaches on the matter of granularity Hildebrand provides, the first topic 
still remains: Hildebrand provides no teaching regarding a graphical user interface for representing 
access log information. 

If claims 45, 46, 55, 58, and 66 are allowable then all claims that depend are similarly allowable. 
In response to action item lie: 

In the interview 2008-05-16 Examiner has suggested and Applicant since that day has accepted to 
narrow claims to access control for documents instead of more broadly claiming access control for 
resources. While some specification language may be about resources, all claims remaining under 
consideration have been narrowed to access control for digital documents. 

Hayes explains (emphasis added) 'TIGS. 12 through 24 show a variety of actual administrator screen 
snapshots in various phases of application administration ". 

Since the Office Action mailed 2008-07-09 Examiner keeps mentioning "a content of resource is 
displayed on the left panel". In the present Office Action mailed 2012-02-09 Examiner finally 
identifies items by number "a contents of the applets 1300 are displayed on the left panel [i.e., items 
1306 and 1308] " which in fact is on the right, not on the left. 

Hayes explains "Attributes of the application that is selected in 1306 are shown at 1308. " It matters: 
An application isn't a document. And, attributes aren't content. 

The present specification narrows the scope of what a document is (emphasis added): 

Representative examples of a "digital document" are a word processing document a 
digital photograph, a digital illustration, a digital engineering drawing, a digital medical 
document, a digital legal document, and a Web page. 

Many contemporary office workers are familiar with a number of common uses of the word 
"document": The first command in the Standard toolbar of Microsoft Word 2002 is "New 
Blank Document". Then, Microsoft Word 2002 names new documents " Document 1 ", 
"Document2 ", and so on. Microsoft Windows XP presents a folder to hold documents 
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which is called "My Documents 99 , which is distinct from the folder "Program Files 99 . For a 
file "example.doc 99 Microsoft Windows XP Windows Explorer shows Type "Microsoft 
Word Document", which is distinct from the same version Windows Explorer for file 
"WINWORD.EXE 99 showing Type "Application". Adobe Systems Incorporated has defined 
the Portable Document Format (PDF) standard. A file in Portable Document Format is 
distinct from Adobe Acrobat, which is application software. Windows Explorer for a file 
"example.pdf 9 shows Type "Adobe Acrobat Document", which is distinct from for file 
"Acrobat.exe 99 showing Type "Application". 

In the context of this disclosure, the term "digital document" is definitely not identical to 
the term "file" from the broadly stated "everything is a file 99 in Unix architecture 
literature. In the context of this disclosure, the term "digital document 99 specifically does 
not include file system directories, does not include devices, sockets, and pipes, and does 
not include system files, system software, and application software. 

Close inspection identifies no document content on the right in Figs. 13-22. There are applet lists, user 
lists, user administration, rights administration, but no document content. What is configured are 
applets, not documents. Applets are like applications, like WINWORD.EXE. Applets are not like 
documents, not like example.doc. As such, applets do not have informational content that normally is 
displayed like document content normally is displayed. 

Examiner argues "Hayes: col. 3, lines 38-45; uses a unique identifier to access the file; which is known 
as a digital document, from the server 99 . It may be relevant to note Hayes in the very quoted col. 3, 
lines 38-45, which is within a section titled "BACKGROUND OF THE INVENTION 99 , describes prior 
art for Hayes, i.e. it is not a paragraph about the workings of Hayes's invention. In those lines Hayes 
writes "Still another limitation in the art lies in the lack of any provision to migrate existing 
applications and hardware into the new environment of the centrally managed network computing 
world without requiring changes to the existing hardware and applications. Existing hardware, a 
terminal for example, in a networked environment, gets its configuration information at boot-up time 
from a file in a specific format located on a server. 99 Hayes describes how prior art terminals get their 
configuration information from a server. 
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Hayes is concerned to some extent with (emphasis added) 'control of user applet execution based on 
group default membership privileges" and (empahsis added) "an access control list to manage user 
access to applications on the server". 

The important point: In systems of controlling elements versus what is controlled, Examiner quoted 
file from the server, which contains configuration information, is one of the controlling elements. 
What is controlled in Hayes are applications, applets. In contrast, the present claims' "normal size, 
legibly scaled, unabridged representation of the content of the specific predetermined visual digital 
document " is part of what is controlled. Analogously, a steering wheel isn't a front wheel, even if it is 
located near the front seat of the car and is a wheel. 

Hayes doesn't deal with documents, let alone with document contents. 

Applicant presents a thought from the current Wikipedia article on "false premise" comes to bear here: 
"an argument based on false premises can be much more difficult to refute, or even discuss, than one 
featuring a normal logical error, as the truth of its premises must be established" . 

As an additional thought, if Examiner considers the configuration information merely to be an example 
of a document and considers Hayes describing a user interface to show that configuration information 
to be an example of showing a document, and uses such logic in the instant Office Action 35 USC § 
103 obviousness rejections of claims 45 and 46 in action item 24, that would beg the question why not 
a less arguable example of a digital document has been chosen as an example. There is prior art 
unarguably showing digital documents: E.g. Microsoft Word, OpenOffice.org Writer, or Internet 
Explorer. In case there is a preference for patent applications as prior art, there must be patent 
applications more simply and unarguably showing document content, for example Ross, (US 
5,929,854). 

Applicant in earlier replies (2008-10-09, 2008-10-16, 2009-03-18) has repeatedly and rationally argued 
Hayes doesn't show document content. Applicant upon review presents those prior arguments still to 
be essentially valid. 

Showing document content is known in prior art. What so far is thought to be absent in prior art, and 
would be worth arguing if found, is relevant log information present next to document content, in such 
ways as disclosed in the present invention and hence enabling non-technical users. 
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In response to action item 12: 

Additional words incorporated into the new specification are merely illustrative examples known to 
one skilled in the art as of the time the invention was made and therefore are not new matter. 

For example, a PDF document has been widely known to be a kind of digital document, one skilled in 
the art would have recognized a PDF document as an example of a digital document, and mentioning a 
PDF document in the present amendment to the specification provides clarification for a narrowed 
claim with scope reduced to a PDF document. 

Also, a "visually compound digital text document" is a kind of digital document. A "visually 
compound digital text document" has been defined to describe an HTML document, yet it would e.g. 
also include future kinds of documents that are essentially the same even if a differently named 
standard would be used. 

Another example, a mention of non-persistent settings "that lose effectiveness when an online meeting 
or session ends or expires " has been provided to clarify what is not claimed. Similarly, saying "the 
Virginia opossum is the only marsupial found in North America north of Mexico; in contrast the North 
American kangaroo rat actually is a rodent hopping similar to a kangaroo, it is not a marsupial" is a 
reasonable clarification of what is not: That kangaroo rat is not a marsupial. Albeit verbose, it may be 
worth mentioning as a clarification for a certain segment of the readership, who might question the 
truth of the Virginia opossum being the only marsupial found in North America. Such kind of 
clarifying exclusionary mention does not constitute an addition of statutory matter. 

In response to action item 14: 

Claims have been amended to have the exact wording "a visual display unit hardware device" in the 
body. 

The substitute specification specifically defines at page 6 line 27 a "visual display unit" is a hardware 
component. Therefore, recitation of the visual display unit within claims recites a hardware 
component. 

One skilled in the art as of the time the invention was made would have known a visual display unit is a 
hardware component. 
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In response to action item 16: 

The specification has been amended to provide a standard for ascertaining the requisite degree of 
"graphically represented essentially at most one time" at page 7 lines 1-11. 

In response to action item 18: 

A 35 USC § 102 rejection is improper when referenced prior art in fact doesn't disclose the claimed 
invention. 

The instant Office Action references Barkley against claim 1. Examiner argues Barkley discloses "a 
display region on the display unit for normal size, legibly scaled, unabridged representation of the 
content of the document". 

Barkley, however, doesn't teach the present invention's carefully defined normal size, legibly scaled, 
unabridged representation of the content of the document, let alone showing it concurrently visible and 
concurrently operable with access control settings. 

Document content in the art and in general is understood as the informational content of a document 
itself, not its metadata. 

Barkley user interface doesn't show document content. 

Applicant has presented more detailed arguments regarding Barkley further above in the present reply 
in section "In response to action item 11c". 

If claims 1, 52, and 63 are allowable then all claims that depend are similarly allowable. 
In response to action items 20-23, and 26: 

The instant Office Action 35 USC § 103 obviousness rejections in action items 20-23 are based on at 
least one false premise. Examiner statement "Barkley discloses the visual display unit graphical user 
interface of claim 1 " has overlooked an essential claim element: Barkley user interface doesn't show 
document content. 

Barkley doesn't teach the present invention's carefully defined normal size, legibly scaled, unabridged 
representation of the content of the document, let alone showing it concurrently visible and 
concurrently operable with access control settings. 
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Applicant has presented more detailed arguments regarding Barkley further above in the present reply 
in section "In response to action item 11c". 

In this context, Applicant respectfully requests to drop this set of obviousness rejections. 
In response to action items 24, 25, and 27: 

Applicant in the present reply above already has refuted many bases of the arguments presented in 
Office Action items 24, 25, and 27. Additional issues are: 

Regarding claims 45 and 46: For both claims 45 and 46, Examiner writes "Hildebrand teaches a 
visual display unit which" ... "comprises: a display region" ... "which comprises" ... "indication 
whether there has been any access at all by the user to the document". Applicant has not found any 
evidence of Hildebrand displaying any information about what has happened (i.e. not any access log 
information). Examiner indicated section and figures (pars. 0108-0109 and 0138 [0135?]; Figs. 2D 
and 5B.1; users can be assigned to different access privileges; see also pars. 0102, 0108-0109, and 
0135; Figs. 2C.1, 2D, and 5B.1) are indicated by Hildebrand to be settings. That is a significant 
difference. Settings can change. One moment in time's (e.g. current) settings do neither positively nor 
negatively indicate past access. One can recognize: Currently allowed access may not have taken 
place, and currently prohibited access could have been allowed in the past and could have taken place 
then in the past. Not settings, but access log information (commonly log entries) has to be the basis of 
"indication whether there has been any access at all by the user to the document". Settings aren't 
good enough. Hildebrand apparently doesn't go near access logging, and doesn't teach user interface 
to show information derived from access log information. 

This very kind of treating details of access control as second-class citizens has lead to a great number 
of leaks of information. Bad access control user interface has lead to people effectively not using 
access control. It shall be noted, while Applicant can only fathom access control in place at the 
USPTO, Applicant would assume a good degree of rigidness, that in recent years in business and in 
highly dynamic private industry rigid access control systems aren't used and are being circumvented 
and hence rendered ineffective, because they prevent the very dynamic that is required. 

A United States that prides itself in intellectual property must not only protect mass produced goods 
(not only but many in entertainment), but it also must be able at the level of the engineer, the small 
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business, and the innovative corporation to both protect pieces of information and yet to allow work 
with those pieces of information. 

It is the very essence of the present invention to describe in detail how to do access control right at a 
fine grained level. It is the essence of the present invention to fill in the very pieces connecting access 
control and user interface which have been overlooked by an industry that collectively has taken turns 
toward ineffectiveness. 

In a United States that has to struggle to keep its leadership, the importance of keeping information 
confidential while being able to work is no less important today than it has been in the past. 

Yet the IT industry's failure to provide usable access control has lead to a young generation entering 
the workforce assuming everything digital must be shared (except copyrighted entertainment). The gap 
between sharing and keeping confidential has become almost insurmountable. Confidential has 
become very rigidly restricted. Confidential cannot be easily administrated by individual users 
(operators). The present invention is a blueprint to get out of that problem. 

Also, regarding claim 46: Examiner writes "Hayes teaches a system with a network interconnecting a 
server and a plurality of user stations wherein the resource is a digital document". 

Hayes is concerned to some extent with (emphasis added) "control of user applet execution based on 
group default membership privileges" and (empahsis added) "an access control list to manage user 
access to applications on the server ". Hayes doesn't deal with documents. 

Where is content of a document together with access control settings for that document, let alone with 
access log information? 

Also, document content in the art and in general is understood as the informational content of a 
document itself, not its metadata. 

Applicant has presented more detailed arguments regarding Hayes further above in the present reply in 
section "In response to action item lie". 

Applicant presents a thought from the current Wikipedia article on "false premise" comes to bear here: 
"an argument based on false premises can be much more difficult to refute, or even discuss, than one 
featuring a normal logical error, as the truth of its premises must be established" . 
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Rejections of claims 45 and 46 form the basis of all other rejections in present Office Action item 24. 
If claims 45 and 46 are allowable then all claims that depend are similarly allowable. 

In response to various "would have been obvious to combine": 

Applicant's responsive comments found in the Amendment filed 2010-06-21 at page 3 line 2 to page 5 
line 3 are herein reiterated and are incorporated in this response by reference, as such remarks remain 
relevant to allowability of the claims, as amended herein. 

In that context, Applicant respectfully asks Examiner to withdraw rejections based on obviousness. 
In response to further arguments: 

Applicant believes amended claims should be allowed, and above remarks should be sufficient. 

Nevertheless, if needed, below are additional observations on further arguments of the instant Office 
Action. 

Hindsight: 

What may seem obvious after reading the present disclosure is not the same as what has been obvious 
at the time the invention has been made. 

MPEP§2142 states: 

To reach a proper determination under 35 U.S.C. 103, the examiner must step backward in time and into the 
shoes worn by the hypothetical "person of ordinary skill in the art" when the invention was unknown and just 
before it was made. In view of all factual information, the examiner must then make a determination whether 
the claimed invention "as a whole" would have been obvious at that time to that person. Knowledge of 
applicant's disclosure must be put aside in reaching this determination, yet kept in mind in order to determine 
the "differences," conduct the search and evaluate the "subject matter as a whole" of the invention. The 
tendency to resort to "hindsight" based upon applicant" s disclosure is often difficult to avoid due to the very 
nature of the examination process. However, impermissible hindsight must be avoided and the legal 
conclusion must be reached on the basis of the facts gleaned from the prior art. 

Context of innovation: 

Not or badly teaching user interface is a common problem in the art of access control: User interface 
for access control is significantly less than optimal. As a consequence people aren't using access 
control as much as they would in traditional office document management of earlier centuries. Hence 
there is a lack of confidentiality, leaks ensue, and the US is suffering economically. Apparently a 
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generation is growing into the workforce with significantly less appreciation for the ability to keep 
documents confidential. 

Access control literacy is not widespread in the world of digital documents, at least in part because its 
user interface has been horrible. The user interface of access control has not been done right. 

That is a problem. 

The present invention teaches better user interface for access control. 

People do what they are familiar with. People make more of what they know. Access control has had 
horrible UI. Horrible UI for access control has become the new normal. Better than horrible isn't 
obvious any more. 

Could it be something as prominent in the 20th century as access control has lost momentum? Maybe 
one reason can be found in Tim Berners-Lee's seminal March 1989 proposal for a global hypertext 
system, which would become the World Wide Web. Berners-Lee wrote: 

Non requirements 

Discussions on Hypertext have sometimes tackled the problem of copyright enforcement and data security. 
These are of secondary importance at CERN, where information exchange is still more important than 
secrecy. Authorisation and accounting systems for hypertext could conceivably be designed which are very 
sophisticated, but they are not proposed here. 

In cases where reference must be made to data which is in fact protected, existing file protection systems 
should be sufficient. 

One could say the original proposal of the World Wide Web in 1989 said "information exchange is 
still more important than secrecy 99 ... "Authorization" ... "not proposed here" ... " existing file 
protection systems should be sufficient". Applicant thinks this section of the proposal, like other parts 
of the proposal, has been followed well by the industry. This is part of the context in which the present 
invention has been made. In contrast to Berners-Lee's proposal, the present invention puts an emphasis 
on and enables access control through innovation. 
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Could it be that making good user interface isn't obvious? Dave Vronay, who after a career start in 
Apple's Advanced Technology Group then spent 15 years at Microsoft in functions including user 
interface research and development and management in the US and China, has blogged about user 
interface design: 

Google has the same issue. They think they are designing things that will be simple and easy for everyone to 
understand, but they don't seem to be able to tell when they go off the reservation. When they were just 
doing search, it doesn't matter. They can distill all of that brilliance into something super simple: a search 
box. But high IQ doesn't mean high EQ. In fact, their EQ - emotional understanding - is probably just as 
low as their IQ is high. And in cases like social - where EQ is at the forefront - they simply can't tell that 
what feels satisfying emotionally to them is far below the bar of the typical human. They just cannot feel 
outside the box. 

Vronay describes how different mindsets can prevent making usable product. 

While information leaks out of IT systems, the IT industry still doesn't provide usable solutions. There 
has been enough capital spent on IT systems which would have allowed the design and implementation 
of better access control. Those who were hired by the industry didn't design and implement it because 
it wasn't obvious to them. The solution presented by the present invention hasn't been obvious. 

Concepts like "competency", "figuring out", and "getting it right" are considered important at 
companies that innovate and make the highest quality and commercially successful products. In an 
April 2004 Knowledge@Wharton interview when asked: 

"Why have Microsoft's attempts not worked? What's the source of your confidence?" 

Bruce R. Chizen, CEO of Adobe Systems Incorporated, has replied: 

"The reason is that our customers care a lot about the visual integrity and reliability of the 
information that is being presented. And that's just not a core competency of Microsoft. 
We've been at this now for 20 years. Everything we do is based on Adobe's imaging model 
and rendering engine — that layer between the operating system and the application, that 
allows us to express information in a way that Microsoft has trouble figuring out." 

Applicant has brought a specific combination of experience and mindset, which combined with 
excessive work hours have enabled him to formulate the present invention. 
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One could think the present invention is a key piece for the consumerization of access control. It is 
needed when individual users are responsible for whom they grant access. These users more often than 
not will be non-technical. These users often are legally liable. These users may have their livelihood 
or at least significant financial results depend on their ability to control information. 

This invention hasn't been obvious because the industry has been thinking in terms of a system 
administrator being responsible for access control. In prior art "the administrator" sets, views, etc.. 
The administrator got horrible user interface. And the administrator didn't speak up. He didn't want to 
seem inept at dealing with it. 

Here is a well known example of what happens when access control is too difficult to set at a fine 
grained level: All documents are set to the same. That's easy. And that has enabled the size of the 
United States diplomatic cables leak, perpetrated by an insider without too much skill. 

HIPAA: 

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 was enacted by the United 
States Congress in 1996. 

To quote from Wikipedia: 

"Title II of HIPAA defines policies, procedures and guidelines for maintaining the privacy 
and security of individually identifiable health information as well as outlining numerous 
offenses relating to health care and sets civil and criminal penalties for violations." 

and: 

"Per the requirements of Title II, the HHS has promulgated five rules regarding 
Administrative Simplification: the Privacy Rule, the Transactions and Code Sets Rule, the 
Security Rule, the Unique Identifiers Rule, and the Enforcement Rule." 

and: 

"The effective compliance date of the Privacy Rule was April 14, 2003 with a one-year 
extension for certain "small plans"." 
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'The Final Rule on Security Standards was issued on February 20, 2003. It took effect on 
April 21, 2003 with a compliance date of April 21, 2005 for most covered entities and April 
21, 2006 for "small plans". The Security Rule complements the Privacy Rule." 

Dr. Bryan Kaufman, a practicing radiologist and former medical industry executive, in 2012 in an 
email has written from a medical professional's point of view: 

EHR systems (i.e. 'electronic health records', containing your X-rays, prescriptions, 
diagnoses, ...every piece of medical data about you), today, still don't have the technologies 
described by Leo Baschy as "User Interface Driven Access Control". Without it, EHR 
systems need paper documentation, with your signature, for every document going out. It is 
crippling to the medical profession (doctors and all medical personnel). To have a patient's 
form sent to another doctor for a second opinion diagnosis, requires a new patient signature. 
The result is, the doctor's office has become the keeper of the information, and the doctor is 
legally responsible to enforce HIPAA, he has been made the keeper of the information. The 
owner of the information, the patient, has no access to the information over the Web right 
now, and has no access control over the information in digital form at all. One of the causes 
driving this, is HIPAA is in effect, and medical IT has not provided fine grained access 
control to patients. In effect HIPAA has become paralyzing more than enabling. 

User Interface Driven Access Control as described in the invention would be a significant 
enabler to reduce the paralysis: 

In the medical setting, patient records are now required by HIPAA regulations to be 
released only under authorization by a patient. Whether to other physicians, insurance 
companies, or family members; no medical facility can release patient records without 
patient consent. 

This would require fine-grained access control of documents when provided online. 

With User Interface Driven Access Control as described by Leo Baschy: 

A patient may not know a physician by name, but will recognize their face. Also granting 
access to family members by using images of those members, allows the medical staff to 
recognize allowed family members, on sight, directly from the document being released. 
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The access control can be provided by the patient remotely. The patient can then provide 
access to referring physicians or individual family members in a secure and auditable 
manner. The documents and images have an attached audit trail demonstrating all of the 
individuals who have viewed the documents in addition to those who are authorized to view 
the documents. Both are required under HIPAA regulations. The presentation of the 
individuals images increases the security of the documents by allowing custodians of the 
documents to verify that the intended individual is the one actually receiving the 
documents. 

Medical professionals do have a problem, and when presented with the present invention often express 
desire to use it. 

In 2009 the Healthcare Information and Management Systems Society (HIMSS) has published a report 
titled "Defining and Testing EMR Usability: Principles and Proposed Methods of EMR Usability 
Evaluation and Rating". To quote verbatim: 

The rate at which EMRs have been adopted in clinic and hospital settings within the United 
States has lagged behind the adoption of information technology that has been common in 
other industries for more than 20 years. 

Multiple causes have been suggested including cost, resistance to change, fear or avoidance 
of technology, and ingrained patterns of behavior. Increasingly, however, usability has been 
acknowledged as a deterrent to adoption, and one that must be addressed. We submit that 
usability is one of the major factors — possibly the most important factor — hindering 
widespread adoption of EMRs. 

Usability has a strong, often direct relationship with clinical productivity, error rate, user 
fatigue and user satisfaction-critical factors for EMR adoption. Clinicians lose productivity 
during the training days and for months afterward as they adapt to the new tools and 
workflow. Some productivity losses are sustained, mostly due to longer time needed for 
encounter documentation in complex patients. 

This HIMSS report is additional evidence that a problem has existed which has impacted or probably 
can impact medical care for patients and which has not been solved in many years. 
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Machine created arguments: 

Applicant by now has the impression the conversation is about sentence fragments that have been 
picked by machines, or at least helped by machine processing, with Examiner attempting at using or 
putting together such fragments to construct relevance, similar to a linguistic exercise, regrettably with 
less comprehension than a human, ideally one skilled in the art, would have. 

While other examples are more subtle, one easy to argue example is the repeated mention of Steinberg. 
Steinberg probably came up in a search for access control and photos. One of a number of queries 
from search history (Applicant merely copies without knowing meaning) reads: 

(digital near (file or photo)) (image near color) ((brightness or contract near 5 adjust) (ad@< "20031703 ") 
((permission or privilege or right) with (access or read or write or modif$5))) (715/741-781 ;7 2 6/2, 2 6- 
30). eels . 

Steinberg modifies photo brightness in the context of imaging. Steinberg modifies photo brightness 
(same shift for each image from the same camera to correct for known camera defect) quite differently 
than Applicant (increase or decrease each ID image toward a common ideal average independent of 
origin of image). Steinberg controls access to photos. Yet Examiner keeps presenting that Steinberg 
does what Applicant does. In fact, Steinberg does something different (control access to photos for 
imaging versus Applicant using ID photos to indicate access control users) and does something 
differently (amount and direction of modification of image) than Applicant. Applicant suggests 
Exmainer's arguments couldn't pass review by a panel of those skilled in the art. When it comes to 
pure logic, the very sentences in Examiner's arguments are factually wrong. Only with an extremely 
blurry vision (hazy understanding of the art) could one come to agree with Examiner's arguments on 
Steinberg teachings compared to Applicant's claimed inventions. 

Conclusion 

Applicant respectfully solicits consideration of his arguments herein, and allowance of the pending 
claims. 



reply 



page 37 of 38 



10/802,658 



Respectfully submitted, 
/Leo Baschy/ 
Leo Baschy 
Applicant Pro Se 

Date 2012-08-08 
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Attachment A: Marked Substitute Specification 

This coversheet to Attachment A is NOT part of the Marked Substitute Specification. The Marked 
Substitute Specification begins on the next page. 



10 User Interface Driven Access Control System and Method 

Related Application 

This application claims priority of U.S. Provisional Application Ser. No. 60/320,013, filed March 17, 
2003 by Baschy, entitled "User Interface Driven Access Control", the content of which is hereby 
incorporated by reference as if set forth fully herein. 

15 Field of the Invention 

The present invention is a method for improving the ease of use of access control systems employed in 
computer information storage, retrieval, transmission, and creation. 

Background of the Invention 

There is a rich body of prior art regarding user interface design, and access control design. Each of 
20 those regions, however, has been traditionally treated without regard for the other, and integration of 
access control into a facile and consistent user interface has not been the focus of development in the 
prior art. Apart from systems that announce user permissions by alteration of an icon (such as by the 
addition of a padlock to the icon of a file to indicate that the file itself has a "locked" attribute), the 
integration of access control into the user interface is largely an afterthought in the prior art. 

25 Brief Description of the Invention 
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Many who practice the art have become accustomed to designing user interfaces separately from other 
elements of their systems. The present invention provides a method for making users of information 
processing systems more productive, in a more secure manner. The present invention provides a 
graphical user interface which integrates access control concepts directly, rather than requiring a 
5 separate system for "permissions" or "user rights" as is common in the prior art. 

Brief Description of the Drawings 

Figure 1 : A module in Apache can control access, but in this implementation the actual decisions are 
being made in the control server. 

Figure 2: Connecting the client user interface through Apache to the control server. 

10 Figure 3: Structured data defines access control settings for a resource. 

Figures 4 to 6: Defining structured data may contain references to other resources within the hierarchy 
of resources. 

Figures 7 to 8: Inheritance within the hierarchy of resources defines access control settings for a 
resource in case there is no directly defining structured data for a resource. 

15 Figure 9: A comprehensive view, with log display. 

Figure 10: Drag and drop a user. 

Figures 1 1 to 23: Sequences of steps in using an implementation of the present invention. 

Figure 24: An example illustration of how composition of access control settings works. 

Figure 25: Different graphical representations for users and groups. 
20 Figure 26: Use of id card representations. 

Figures 27 to 29: Arranging representations of known users, groups, and macros. 

Figures 30 to 34: Overflow indicators. 

Figures 35 to 39: Reviewing what another user has access to. 

Figures 40 to 49: Examples of access dependent contents. 
25 Detailed Description of the Invention 
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For the purpose of clarity of this disclosure, the term "operator" has been used to identify the person 
who directly interacts with the "user interface", which hence would better be called "operator 
interface", were it not for the fact that "user interface" is an established term. Because the present 
invention concerns itself with access control, one "user" or several "users" may be depicted in the user 
5 interface, as well as "groups" of users. Users and groups are given access privileges for resources by 
the operator. The operator himself may also appear in the user interface, as one of a number of users. 

The term "likeness of a person" means an identifying pictorial representation of the person, an imitative 
image, e.g. an identifying photograph, possibly a modified photograph or a machine processed image 
of that person that sufficiently corresponds to the person's appearance to allow a normally skilled 
10 human to identify the person in an encounter with normal visual contact. Examples of "likeness of a 
person" are in Figures 9 to 30 and 32 to 34. 

A "normal size, legibly scaled, unabridged representation of the content of a resource" is what 
commonly is shown in normal use by a word processing application or by a drawing software when the 
operator views or edits a document. Examples of "normal size, legibly scaled, unabridged 
15 representation of the content of a resource" are display regions 401 and 501 in Figures 9 to 23 and 26. 
A "normal size, legibly scaled, unabridged representation of the content of a resource" is different than 
a thumbnail of a drawing or a summary of a document. 

A display region for access control settings for a resource and a display region for content of the 
resource are "concurrently visible and concurrently operable" if the operator can choose to initiate a 

20 function in either region without having to effectively put away the other. It will be appreciated by one 
skilled in the art that recognizable examples of "concurrently visible and concurrently operable" 
display regions are in Figures 9, 1 1 to 16, 18, 20 to 23 and 26, where all display regions are visible at 
the same time and all display regions by using the same minimal number of steps by the operator can 
be interacted with equally immediately to initiate functions, with such steps required to initiate a 

25 function in contemporary art frequently being one mouse movement and one mouse button pressing 
and one mouse button releasing, the steps of pointing and clicking. In contrast, a modal dialog box for 
access control settings would not be concurrently operable with a document content region, as the 
modal dialog box would block editing of document content until after the modal dialog box goes away, 
such going away e.g. caused by the operator clicking on an Apply or Cancel button in the dialog, 

30 although then with the document content region being operable the modal dialog box would neither be 
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visible nor operable until initiated to be shown again and to block editing again. Also in contrast, 
tabbed panes don't provide concurrent visibility, i.e. settings and content if in two separate panes 
wouldn't be concurrently visible. 

"Revocable access control settings" are access control settings that at a future point in time can be 
5 changed so that e.g. a person who has had access then will no longer have access, or e.g. a person who 
has had write access then only will have read access. Being "revocable" is considered normal for 
access control settings. The ability for a user to be "removed from access to" a resource is intrinsic to 
the present invention, evidenced at least by the mention of removal. "Revocable" is in contrast to non- 
revocable access, e.g. in contrast to commonly used email, which once a message has been sent no 
10 longer allows for a recipient to be removed. "Revocable" is essential to allow correction of operator 
errors. "Revocable" is required when changes in circumstances lead to changes in "need to know". 
"Revocable" can help reduce information overload. "Revocable" enables reducing access after a 
document (e.g. medical record, legal record) or its surrounding real world matter (e.g. medical case, 
lawsuit) has been dealt with (e.g. patient discharged, case closed). 

15 "Persistent access control settings" are access control settings that are stored persistently, often to disk, 
in such a way that users and other parties expect them to last for lengths of time that for most practical 
purposes appear to be without end. Being "persistent" is considered normal for access control settings. 
"Persistent storage" of access control settings is intrinsic to the present invention, evidenced at least by 
repeated mention of persistent storage 155. "Persistent" is in contrast to non-persistent settings, e.g. in 

20 contrast to settings that last only for the duration of an instant messaging conversation, an online 

meeting or an online chat. "Persistent" is required for collaboration among those in different working 
periods (day shift versus night shift), for collaboration across distant time zones, for collaboration 
without "same time presence", for long running workflows and for all situations where the expectation 
is for "records to remain constant for a long time". 

25 In some embodiments, notwithstanding above definition, "persistent access control settings" may come 
to an end purposefully in a controlled manner at contextually meaningful, defined points in time, e.g. 
after 30 days or when a patient has been discharged. Access control settings that come to an end in a 
controlled manner at defined points in time may or may not be known in prior art and are mentioned 
here solely for the purpose of more clearly defining what still should be considered "persistent access 

30 control settings", by its nature as well as by its probable implementation using persistent storage. 
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"Persistent" is in contrast to non-persistent settings, e.g. in contrast to settings that are lost when a 
controlling application or computer in a normal course of events or typical use shuts down, suspends or 
restarts , or that lose effectiveness when an online meeting or session ends or expires . "Persistent" 
fulfills more significant needs and has more essential impact on the productivity of professionals than 
5 non-persistent. Professionals often need access control settings that remain constant and behave 
predictably, i.e. without undue susceptibility to surrounding events. 

"Persistent yet revocable access control settings" are access control settings that are persistent by 
default yet allow revocation if needed. Being "persistent yet revocable" is considered normal for access 
control settings. 

10 The present invention can be applied to many kinds of "digital documents". Listing some applications 
to specific kinds of digital documents helps bring home the fact that prior art has left professionals 
without the tools they need. 

Representative examples of a "digital document" are a word processing document, a text file, a digital 
photograph, a digital illustration, a digital engineering drawing, a digital audio recording, a digital 
15 medical record document , a digital legal document, and a Web page and a source code file . 

Many contemporary office workers are familiar with a number of common uses of the word 
"document": The first command in the Standard toolbar of Microsoft Word 2002 is "New Blank 
Document". Then, Microsoft Word 2002 names new documents "Document 1". "Document2", and so 
on. Microsoft Windows XP presents a folder to hold documents which is called "My Documents", 

20 which is distinct from the folder "Program Files". For a file "example.doc" Microsoft Windows XP 
Windows Explorer shows Type "Microsoft Word Document", which is distinct from the same version 
Windows Explorer for file "WINWORD.EXE" showing T ype "Application". Adobe Systems 
Incorporated has defined the Portable Document Format (PDF) standard. A file in Portable Document 
Format is distinct from Adobe Acrobat, which is application software. Windows Explorer for a file 

25 "example.pdf ' shows Type "Adobe Acrobat Document", which is distinct from for file "Acrobat.exe" 
showing Type "Application". 

In the context of this disclosure, the term "digital document" is definitely not identical to the term "file" 
from the broadly stated "everything is a file" in Unix architecture literature. In the context of this 
disclosure, the term "digital document" specifically does not include file system directories, does not 
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include devices, sockets, and pipes, and does not include system files, system software, and application 
software. 

Despite distinguishing software from documents, ancillary scripting in a document that essentially 
carries data does not automatically disqualify the document from being a "digital document". E.g. 
5 embedded JavaScript that on load checks a table of contents against section headings doesn't cause a 
containing document which is rich in content to "be software". 

In the context of this disclosure, a "visual digital document" is a "digital document" for the essential 
content of which exists a "normal size representation of the content of the document" which a 
professional would use for viewing and editing the content of the document. Noteworthily, "normal 
10 size representation of the content of the document" does not require a life size representation of a real 
world object represented in the document. 

In the context of this disclosure, a "visually compound digital text document" is a "visual digital 
document" that generally appears to the user as one document as it is visually represented by 
intermingling its own independently meaningful substantial text content with supplemental substantial 

15 image content from at least one separately locatable image file which it references, which image file 
optionally could be viewed independently. A common representative example of a "visually compound 
digital text document" is a HyperText Markup Language (HTML) document which includes an image 
by means of an "IMG" element with a "src" attribute specifying the location of the image resource. An 
"<IMG src=" included image could be located by its URL by itself and viewed by itself (without 

20 needing the HTML page), and the text of a containing HTML page can be located by its URL by itself 
and can be parsed for its English meaning by itself (without needing the included image). As examples: 
The text of a research report should be independently meaningful, an illustration would supplement it. 
In contrast, a rudimentary HTML wrapper around a photo with merely a file name above the photo 
isn't substantial, and the photo isn't supplemental as it is the main content. 

25 A "Portable Document Format document" is a document in the format "Portable Document Format" 
(PDF) created by Adobe Systems Incorporated. 

A "visual display unit" is a hardware component that displays images generated from the output of 
devices such as computers. Contemporary examples of a "visual display unit" are thin film transistor 
liquid crystal screens, cathode ray tube monitors, electronic paper, organic light emitting diode display 
30 screens, and the like. 
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To describe a "graphical representation of a set comprising a plurality of individual users wherein each 
of the individual users is graphically represented essentially at most one time" positively confirms use 
of the common meaning in computer science and mathematics of a "set" to store no repeated values. 
Figure 9 columns 420. 430, 440 for each user show only one row. 

5 To describe a "graphical representation of a set comprising a plurality of individual users wherein each 
of the individual users is graphically represented essentially at most one time" is to describe essentially 
"at most one time" yet would allow placement of extraneous representations under some 
circumstances, e.g. in a tooltip, or would allow user interface gimmicks, e.g. a simulated reflection on a 
virtual metallic bevel border around the display region, or would allow e.g. stereoscopy. Neither of 
10 such extraneous representations should defeat an essential property of a graphical representation of a 
set being to show no repeated value. 

Names used in examples herein are intended to be fictional. 

The present invention works with, and builds upon systems that give identified, and sometimes 
unidentified users access to resources, which are defined to include both informational units (files, data 
15 streams, etc.) and physical elements of a computing system (devices, channels, storage space, etc.). 
Resources, as used herein may also be extended to certain physical resources under the control of an 
information system, such as a sensor, control, or other device. The present invention may be 
implemented as an enhancement to file servers, databases, operating systems, and other systems. 

At the time of this disclosure, the best mode contemplated by the inventor for carrying out the present 
20 invention is an implementation as an enhancement to the publicly-available Apache Web server 
software. It is expected, however, that once the usefulness of the present invention has become 
apparent to more people, the present invention will be considered in the design of new system 
architectures. Because of relative complexities of retrofitting into existing architectures, such as 
Apache, careful balance has been struck in this disclosure in order to provide a clear and concise yet 
25 still full and exact description of the present invention. In order to encourage widespread adaptation, 
neither a specific programming language nor a specific graphical user interface object library are 
required. 

In order to implement the present invention, skills in both user interface engineering and access control 
engineering are required. In both fields there are practitioners of greatly varying levels of skill and 
30 experience. As an example, in user interface engineering there are those who solely have used user 
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interface libraries and claim to have user interface engineering experience, and then there are those who 
have designed the libraries used by hundreds of thousands of others, e.g. Java Swing, or who have 
authored leading edge drawing software, e.g. Macromedia Freehand. As another example, in access 
control engineering there are many who have configured servers, while there are fewer who have 
5 designed actual executing code, e.g. mod ssl, or who have authored leading edge security software, 
e.g. PGP. The quality of an implementation will greatly depend on the skill and experience of those 
who engineer it. Other skills that might be considered distinct and helpful include experience in 
network protocols, markup language, and general system architecture. 

According to the theory and practice of the present invention, "looks do matter." In order to achieve the 
10 highest rates of correct decisions by operators in the shortest possible time with least effort, what the 
operator sees is of critical importance. Beyond a certain point, quantitative differences in visual 
appearance become qualitative differences. By analogy: If the font size of text is below a certain size, 
e.g. below four, then no one can read at all; if the font size is above a certain number, e.g. above thirty, 
then most people can read even if they didn't bring their glasses and would need glasses for regular 
15 sized text, e.g. for size ten. A quantitative difference in font size effects a difference in whether people 
can read at all, i.e. a qualitative difference. 

According to the theory and practice of the present invention, there are practical limits to the amount of 
abstract reasoning that should be demanded of an operator of a system. These limits may be different 
from person to person; the limits may be different for a one-time effort and for repeated performance. 
20 According to the theory and practice of the present invention one can achieve much higher rates of 
correct decisions by operators by relieving them of the need to perform complex symbolic mental 
operations. 

The present invention displays both the definition of access control settings as well as effects of access 
control settings. As an example, if settings for a resource have been made for user "Lee" to be allowed 
25 to write, user "Rolf and group "Marketing" to be allowed to read, then the operator might try to 
remember who is in Marketing. According to the present invention, the operator may automatically 
display all individuals including those in the Marketing group: i.e., Lee, Rolf, and users Hank, Thomas, 
and Christoph. 

It must be remembered that a system may be made less useful by the display of additional information. 
30 A system designer must consider people's ability to comprehend displays of information. One must 
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consider the limits of display space, as dictated by the limits of screen sizes. If trying to achieve virtual 
ubiquity, then the limits of display space must be a fraction of the screen size. 

The present invention incorporates methods to balance the amount of information with the amount of 
display space available. The present invention organizes information display in ways that are optimal 
5 for achieving the highest rates of correct decisions by operators. The present invention includes, in 
addition, alternate display region layouts for different tasks. It should also be understood that 
multidimensional regions may be used interchangeably with two-dimensional regions in display 
systems that permit representations or simulations of such regions, and that in referring to a "region" of 
a display herein, the term "region" may be employed without departing from the spirit of the present 
10 invention. 

Implementations of the present invention may require one of skill in the art to be familiar with a 
number of software platforms, architectures, programming languages, standards, and specifications. At 
the time of this writing, extending Apache effectively requires C, actual user interface objects might 
best be written in Java, using and extending Java Swing, graphics operations might best be performed 

15 using libraries such as Java 2D Graphics, or Batik, modules may best communicate with each other 
with API calls, or over TCP/IP streams, wherein the data which is exchanged might best be encoded 
using XML, and access control settings might best be stored using LDAP, or Berkeley DB. HTTP, a 
protocol, might be used plain, or over Secure Sockets Layer (SSL) or Transport Layer Security (TLS) 
protocols, aka HTTPS. WebDAV extensions to HTTP could be used or supported. Further known 

20 elements of software architecture that may make a difference in performance, reliability, and scalability 
include memory management, and concurrency management, and those are within the skill of those in 
the art to identify and implement. 

This disclosure relies greatly on descriptions of graphical user elements, including descriptions of 
layouts of graphical user elements, of constraints of layouts, of changes in layouts in reaction to 
25 operator action, and of changes in layouts in reaction to other events, in terms familiar to those skilled 
in the art. The terms used have been chosen so that one skilled in the art, familiar with at least one user 
interface object platform, can with relative ease make graphical user elements of that platform behave 
as described. 

Because of the different ways user interfaces have been and may be implemented, if the goal is to 
30 achieve a constraint then for the purpose of this disclosure it is best to describe the constraint rather 
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than to describe instructions how to enforce the constraint (e.g. if two elements, one above the other, 
together are to keep a constant vertical dimension, then there are many different ways how code could 
be written that ensures that together they keep a constant height). By way of further illustration: If one 
element changes height it could send a message to the other, and vice versa. But, would it do so before 
5 or after changing its own height? Which element would perform the calculation to determine the height 
for the other element, the one initially changing, or the other element itself, or a supervising object? 
Would there be a short moment in which the total height actually would not equal the desired constant 
value? If so, then is that moment protected against concurrent access by another process thread? Could 
that momentary situation possibly flicker onto the screen? For the purpose of clarity of this disclosure it 
10 is better to simply state that the two elements are constrained together to a constant height. One skilled 
in the art can implement necessary constraint code to be compatible with, and making good use of what 
is available already in the user interface object platform that is being employed. 

Another example for the duality of description and instruction are found in contemporary user interface 
design environments, e.g. Borland JBuilder 8 or NetBeans 3.4. With a few clicks of the mouse button, 

15 one can switch among three different ways of setting the size of a user interface element: (la) One can 
drag the lower right corner of a representation of the user interface element, (lb) one can type width 
and height into a table of properties of the user interface element, or (2) one can directly edit an 
instruction in source code, most of which is being generated automatically, where a line reads 
something like "setSize(500,300)". One skilled in the art is accustomed to translating between (1) 

20 descriptions, e.g. as given in this disclosure, and (2) instructions necessary for a specific user interface 
object platform. 

Interfacing With Apache Web Server Software 

Despite the promises of, and possibilities opened by designing completely new system architectures, at 
the time of this writing, interfacing with Apache Web server software is the inventor's preferred 
25 embodiment. 

Nevertheless, while specific techniques for interfacing with Apache are disclosed herein, these 
techniques are not essential to implementing the present invention. 

One aspect of improving ease of use is to employ an underlying model of access control that better 
lends itself to user comprehension. To implement a new underlying model of access control with 
30 Apache Web server software one may implement a custom Apache module which makes use of 
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Apache hooks check_user_id and auth_checker. A "hook" is an optional invocation through a pointer 
in a data structure, a technique used in coding close to the machine level, often to allow future 
extension of code through modules by other parties, here used as prescribed by the Apache Web server 
source code and its architecture. Hook checkuserid checks user identity, i.e. whether the user is 
5 authentic, whether the user can prove to be who the user id represents, e.g. by verifying whether the 
user knows a secret password. Hook authchecker checks access rights, whether the user is authorized 
to access the resource. 

Source code of prior art modules that check access rights is available with Apache open source 
distributions. Examples are mod auth, mod auth digest, and mod auth dbm. Additional 
10 understanding of such modules can be gained from reading documentation for directives that are used 
in the configuration of access rights, which include Require, AccessFileName, AllowOverride, 
<Limit>, <LimitExcept>, AuthName, AuthType, optionally AuthUserFile, AuthGroupFile, also 
Satisfy, and AuthAuthoritative, and also Allow, Deny, and Order, and also from documentation 
regarding per-directory .htaccess configuration files. 

15 Figure 1 shows where the custom Apache module 15 1 is located in order to create a point of control for 
all access 101, 103, 105, 110, 130, 132 from client software 100, 102, 104 to resources 131, 133 which 
are managed by the Apache Web server software 120, which must have been configured 121 properly. 

From the custom Apache module 151 one can implement a connection 152 to control server software 
153. The control server could be on the same CPU or on a different physical or virtual machine. The 
20 control server could retrieve 154 access control settings from persistent storage 155, e.g. a database, 
using a library like Berkeley DB, using a library like OpenLDAP, or using custom B-tree code, 
possibly inside the same file system as the documents served by the Web server. 

The present invention differs in one respect from prior art modules in that it locates the decision 
whether the user is authorized to access the resource, i.e. the decision of hook auth checker, in the 
25 control server. Prior art modules locate the decision of hook check user id with the help of database 
files or servers, but then in their own code use rather simple logic to interpret Require directives from 
httpd.conf and from .htaccess files. This difference facilitates implementation of alternative models of 
access control. 

This difference is helpful in the development of the present invention, but it is not the essence of the 
30 present invention. It is not mandatory for an embodiment of the present invention to have the custom 
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Apache module connect to a distinct control server. Instead, necessary logic could be coded into the 
module itself. 

To further illustrate the distinction or relative independence between (1) the logic of the model, (2) the 
packaging or location of the code which is used to operate according to the model, and (3) the 
5 permanent or even temporary storage of control settings data according to the model, one should 

consider that as another option, advantageous or not, one could implement a control server that reaches 
back into the very file system which is being served by the Apache Web server software, and within the 
directories in that system works with data in .htaccess files. 

The custom Apache module when invoked via hooks check_user_id and auth checker receives as 
10 parameter a pointer to to a structure requestrec. From that requestrec, either through following 
pointers through members in structures, or through function calls, a number of important facts about 
the request can be retrieved. Those facts include the user id, the URI path, and the HTTP method of the 
request. 

For a simpler model of access control, one should map the larger number of HTTP methods to a 
15 smaller number of access methods. One possible mapping is down to two: READ and WRITE, with 
GET, HEAD, and POST mapped to READ, all other HTTP methods mapped to WRITE, including 
PUT, and DELETE. The reasoning behind this example mapping has to do with actual use of HTTP 
methods, specifically common use of POST for queries and use of HTTP methods by WebDAV, rather 
than what would come to mind when reading RFC 2616. 

20 The present invention further differs from prior art modules, which follow the sequence of Apache 
Web server hooks, by first checking access rights, and then checking identity. If anonymous access is 
permitted for the resource, then checking identity may be skipped, since then no error condition exists 
because checking identity may have failed, and then logging should not record a user identity. To ease 
implementation, the custom Apache module for each request may store information of its choice 

25 between the earlier invocation of hook check_user_id and the later invocation of hook auth_checker. 
As an auxiliary measure, the custom Apache module should enforce use of a single dummy directive 
line "Require valid-user", and an error message should point out and prevent any occurrence of a 
Require directive which lists users or groups. These differences are helpful in the development of the 
present invention, but they are not essential to the present invention. 
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Further differing from prior art modules, the custom Apache module should preferably require itself to 
be configured in a context of server config, or virtual host, and it should raise an error if it finds an 
attempt to configure it in a context of directory, or .htaccess. Further differing from prior art modules, 
the custom Apache module should raise an error if it finds an attempt to configure it together with 
5 directive Satisfy any. These differences are helpful for better overall security through less unintended 
effects in configuration files, but they are not essential to the present invention. 

The custom Apache module may or may not use techniques equivalent or similar to prior art modules 
for checking user identity. Nevertheless, the function implemented for hook checkuserid still should 
be coded specifically for the custom Apache module in order to perform additional tasks. 

10 The code in the custom Apache module which checks access rights may actually be invoked inside the 
function implemented for hook check user id, in order to avoid checking user identity in case of 
anonymous access being permitted for the resource, while much of the handling of the result of 
checking access rights would be done inside the function implemented for hook auth_checker. 

The custom Apache module when processing a request, i.e. when invoked via hooks check user id and 
15 auth checker, when communicating with the control server should pass to the control server as 

parameters (1) the user id, (2) the URI path, and (3) the access method. The result determined by the 
control server should tell either (1) that the user is authorized to access the resource with the requested 
access method, (2) that the user is not authorized to access the resource with the requested access 
method, or (3) that anonymous access is permitted for the resource for the requested access method. 

20 While Figure 1 concerns itself with access control as it occurs when users try to access resources, 

Figure 2 concerns itself with how access control settings can be controlled by an operator, who has to 
be a privileged user, e.g. a user who has authored a document would use the mechanisms of Figure 2 to 
give access privileges to the intended audience, e.g. several individuals, other users. Subsequently, 
those users would use the mechanisms of Figure 1 to read the document, although some, or all of them 

25 may have access to the mechanisms of Figure 2, depending on whether they are privileged enough 
themselves. 

While Figure 1 deals with the question: "May user access resource? 55 , Figure 2 deals with the question: 
"How does operator set which users may access resource? 55 
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Referring now to Figure 2 the operator, using either client software 100, or 104, is presented with 
additional display region 200, or 220. Standard browser components 202, 222, as in Figure 1, access 
101, 105, 110, 130, 132 resources 131, 133 via the Apache Web server software 120, under control of 
the custom Apache module 151. Additionally, user interface components 200, 220 need to 
5 communicate with the control server 153 as well. 

Figure 2 shows user interface components 200, 220 communicating over HTTP, or HTTPS connections 
201, 221, 110 with the Web server 120. The Web server must have been configured 121 properly to 
dispatch 170, 171, 172 those communications to custom servlets 180 which further communicate 181 
with control server software 153, which can retrieve 154 and modify 156 access control settings from 
1 0 and in persistent storage 155. 

It will be appreciated by one skilled in the art that with (1) user interface components 200, and 220, (2) 
custom servlets 180, (3) control server software 153, and (4) control server persistent storage 155 there 
are already at least four separate, albeit connected or related, pieces of code among which one can 
choose where to implement algorithms for user interface for access control. In practice, decisions have 

15 been based on circumstances including licensing conditions, software and hardware pricing, access to 
source code, availability of tools, and last not least staff skills. Other considerations should include 
expected usage patterns, hence relative frequency and nature of distinct operations, expected size of 
control settings data, individually and collectively, estimated numbers of entries, expected bandwidth 
usage, available bandwidth, encryption requirements, processor usage, and size of memory based 

20 caches. 

What has been described in this section should be considered necessary technicalities for the purpose of 
connecting essential innovative elements of the present invention into the Apache Web server 
architecture. Connections into other architectures depend on technical details of the specifications and 
implementations of those architectures. Retrofitting into existing architectures in general requires more 
25 development effort than is required for fitting into an architecture that is newly being designed under 
consideration of the present invention. 

Underlying Model 

One aspect of improving ease of use is to employ an underlying model of access control that better 
lends itself to comprehension. 
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Once interfaces to existing systems, e.g. Apache Web server software, have been defined, 
implemented, or established, there are still a plurality of choices for almost any aspect of implementing 
the present invention, including programming languages, communication channels between modules, 
encoding of data, storage of data, libraries for GUI, and libraries for graphics. The descriptions which 
5 follow here, therefore, use terms and concepts that should reasonably well fit with more than one of 
those options. As an example, a structure made of members could be a struct in memory in C++, it 
could be an object in Java, it could be a node in an XML document, it could be an entry in an LDAP 
directory, or it could be a record in a database. Those implementing the present invention should be 
familiar with converting among such modes of storage, description, or encoding, as needed. Examples 
10 of conversion include: HTTPS to HTTP by proxy directive, XML elements to DOM objects by parsing, 
and almost anything to almost anything else by code in a Java servlet. 

As disclosed herein, the present invention concerns itself with techniques for when given (1) a user id, 
(2) a URI path, and (3) an access method then making the decision whether access is (1) authorized, is 
(2) not authorized, or is (3) permitted to be anonymous. It might be easier to gain understanding of the 
15 present invention by first ignoring the anonymous option, and focusing on whether authorized, or not 
authorized. 

The present invention uses structured data to define access control settings for a resource. It conveys 
information in the form of visual elements, such as icons, photographs, textual indicia, and the like, 
intended to convey information about the meaning of the structured data to a user in a simple, 
20 consistent, and comprehensible manner. 

As used herein, "structured data" may be taken as follows: If there is a set of users Joe, Bob and Dan, 
then most people in the field of information processing can easily agree that they would recognize a 
variety of representations in memory or on a storage medium as data: A properly delimited sequence of 
characters, an array of references to name strings, a collection of objects, etc. 

25 If the definition would be the union of a set of users Joe and Bob with another set Bob and Dan, then 
there might be some representations of that definition which some people would like to argue is, or 
comprises code. For the purpose of this disclosure, however, which concerns itself with the display of 
information, there is nothing but structured data. The duality of data and code is obvious at least when 
so-called code is generated by some compiler or operated on by a code manipulation tool, e.g. an 

30 optimizer: Then code is treated as data. Traditionally in Lisp the definition of functions is data itself. 
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Java byte codes are code, but they are bytes, hence data. Compiled C++ code might be hardware brand 
specific, but it still is made of bytes, hence data. 

As an example, Figure 3 shows for the resource identified by the path 300 there is 301 structured data 
302 that defines access control settings for the resource. With common sense one can recognize in this 
5 simple example what a good implementation of the present invention can recognize with programmatic 
exactness: User Lee is allowed to write 303, user Rolf and every user in group Marketing are allowed 
to read 304. 

The present invention departs from prior art in that the defining structured data may contain references 
to other resources within the hierarchy of resources. Access control settings of such referenced other 
10 resources, if there are any, are by predetermined algorithm merged with the structured data to 

determine effective access control settings for the resource. One easily comprehensible predetermined 
algorithm is to perform unions of the sets of entities which make up the access control settings of the 
referenced other resources and the corresponding sets of entities which are defined by the structured 
data. 

15 As an example, Figure 5 shows for the resource identified by the path 320 there is 321 structured data 
322 that defines access control settings for the resource. It contains a reference 327 to another resource, 
which in this example is the resource from Figure 3. Figure 6 shows effective 331 access control 
settings 332, which result from merging settings, specifically from performing a union of the 
corresponding "allow write" sets 303, 323 to determine the effective "allow write" set 333. 

20 The present invention further allows inheritance within the hierarchy of resources to define access 
control settings for a resource, in case there is no directly defining structured data for a resource. 
Inheritance within the hierarchy may be either from the first instance of defining structured data found 
in the ancestral chain only, with searching starting from the resource itself, or it may perform an 
accumulative operation on multiple instances of defining structured data found in the resource's 

25 ancestral chain. 

As an example, Figure 7 shows for the resource identified by the path 340 there is no structured data 
that defines access control settings for the resource. There is 361, however, structured data 362 that 
defines access control settings for its parent 360 within the hierarchy of resources. Figure 8 shows 
effective 351 access control settings 362, which are inherited from the parent. 
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When using the techniques of the present invention described in this section, (1) dependencies of 
access control settings for resources can be created which with a reference can reach across branches to 
anywhere within the hierarchy of resources, (2) rules for merging settings can be easily 
comprehensible, and (3) a number of inheriting resources can share a single instance of defining 
5 structured data. 

An excellent example for the advantages of these techniques is the case of a document that by reference 
includes an image, which may be in a directory on a different branch of the hierarchy, as in Figures 3, 
4, 5, and 6. If the access control settings defining structured data for the image contains, possibly 
nothing but, a reference to the document then the image automatically should be accessible to all users 
10 who can access the document, unless, to be exact in this description, one has taken extra effort to make 
additional settings. When an operator modifies the access control settings for the document it then is 
not necessary for the operator to make any changes for the image. The dynamic nature of the reference 
ensures that the image automatically will be accessible to all users who can access the document even 
as that set of users may change. 

15 In order to always correctly reflect changes occurring in access control settings defining structured 
data, i.e. to correctly propagate such changes to when and to where access control settings are being 
used, an implementation of these techniques, as should be obvious, must avoid storing effective access 
control settings unless for every cached effective access control setting there are mechanisms put into 
place to invalidate that cache when appropriate. 

20 An example for using more than one reference in one defining structured data could be a biologist's 
photo of a rare beetle which would be required to be seen both by relatives, who get a personal letter, 
and by colleagues, who get a scientific paper. Having two references in one defining structured data is 
key to keeping effective access control settings correct without requiring operator intervention, even 
when relatives or colleagues are being added to or removed from access to the letter and to the paper 

25 respectively. 

Examples for use of inheritance could be any directory containing any size number of files, e.g. photos, 
publications, correspondence, messages, or office records, but also e.g. records from a database or other 
source which are exposed through a URI syntax. 

In implementations of the techniques of the present invention it may become useful to enforce limits on 
30 the complexity of hierarchies of dependencies by reference. One possible limit could be a maximum of 
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one reference per defining structured data. Even more strict would be if that maximum one permitted 
reference if present would preclude any other contents in the same defining structured data, which 
effectively would allow either a reference to another resource, or directly defined access control 
settings only, but not both, no merging. Some kinds of limits could ease implementation of caching 
5 techniques and other algorithms. (It is also useful to anticipate the creation of circular references of 
access, and to properly parse and handle such references.) 

In practice, it has proven useful to the inventor to use two special ids for special meanings: (1) "*", 
Unicode x002A Asterisk, for any validly identified user, and (2) "+", Unicode x002B Plus Sign, for 
anonymous. 

10 One skilled in the art can find more than one way to implement access control which practices the 
techniques described in this section. In at least one implementation, access control which 
comprehensively practices the techniques described in this section has been implemented successfully 
in less than one hundred kilobytes of source code, fitting into Apache Web server software as 
independently compiled module, storing access control settings defining structured data with an LDAP 

15 server, and providing a user interface of HTML frames, forms, and tables through the use of servlets. 

What has been described in this section could be implemented independently from other techniques of 
the present invention. The techniques in different sections of this disclosure work together well, 
enhance each other, add to each other's strengths, have been developed to meet or solve the same, 
similar, or interdependent needs or problems, serve the same purpose, work towards a common goal, 
20 play together like instruments in an orchestra, but they could be employed independently. If described 
independently each section might sound like an instrument in an orchestra playing on while the other 
instruments have turned mute, i.e. somewhat out of place, lonely and disconnected. 

Graphical User Interface 

Ideas that have guided and should guide the development and implementation of the present invention 
25 include: 

(1) If people initially have difficulties understanding something then showing them different views of 
the same matter often improves their understanding. 

(2) If people have difficulties understanding a set of rules then showing them the effects of the rules 
applied in reality often improves their understanding. 
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(3) If something is made easy enough then people are more probable to use it consistently. 

(4) If operator preferences are not known in advance then making the user interface adjustable allows 
the system to accommodate operators on the spot. 

(5) If access control information can be represented in a small enough display region then it can 
5 become a fixture in the display of any and all resources. 

(6) Good user interface should help its targeted group of operators to consistently make the correct 
decisions with the least amount of effort. 

Figure 9 shows a moment in the user interface of an implementation of the present invention. For a 
given URL 400 the Web browser shows a familiar representation 401 of the document. Adjoining there 

10 is a region 410 with a representation of the effective access control settings for the document. User Lee 
41 1 has write privilege, as indicated by a green pencil next to the user's id. Group Marketing 412 has 
read privilege. User Rolf 413 has read privilege. Further adjoining there is a comprehensive 
representation of log information. Organized like columns and rows in a table, for each individual user 
420 it shows the most recent write access 430, and the most recent read access 440. A clock icon 

15 indicates that user Lee has written the most recent version. Eye icons indicate that user Lee and user 
Hank have seen the most recent version. Faded stamp icons indicate that user Thomas and user Rolf 
have seen an old version. A blank entry indicates that user Christoph has not yet seen the document at 
all. Blank entries in the write access column indicate that no user except user Lee has modified the 
document by writing, which could be expected in this case as user Lee is the only user who has write 

20 privilege. 

Figure 10 shows a moment in the user interface of another implementation of the present invention. For 
a given path 500 of a directory the browser shows a familiar representation 501, which without 
relevance to the present invention happens to be generated by the server from an index.html file by 
using a well known technique. In an integrated tree view 505 of the hierarchy of resources the directory 
25 is highlighted for clarity. In an integrated control region, check boxes 510, 511,512, 513,514 allow the 
operator to invoke functions which add and remove display regions with different representations of 
access control information relating to the selected resource, in this example i.e. the given directory. In 
this example the check boxes also provide feedback as to which display regions are currently being 
shown. 
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Adjoining there is a region 520 with a representation of the effective access control settings for the 
document. User Lee 521 has write privilege, as indicated by a green pencil next to the user's id. 
Adjoining there is a region 530 with a sentence fragment that summarizes the reasons why the effective 
settings are such as they are. Other examples in this disclosure show different wording in that region. It 
5 is a subtle hint to beginning operators who are not yet familiar with the symbolism of the user interface, 
a symbolism that both has to correctly convey matters of access control settings as well as it has to fit 
into limited display regions, hence a symbolism that may have to do things in innovative ways, such 
innovative ways then requiring explanation. One could think of it as optional help for beginning 
operators. Check box 512 could switch off this region 530. 

10 Adjoining there is a region 540 with a representation of the directly defining structured data for the 
resource, which in this example implementation also is called "resource entry". Another example in 
this disclosure shows somewhat more complex information in that region. User Lee 541 is being 
defined to have write privilege, as indicated by a green pencil next to the user's id. In this region 540 is 
where settings actually can be manipulated. That possibility is hinted at by the white background 

15 region, which is in contrast to the previously described two regions 520, 530, which have gray 

background to indicate that they only display resulting facts that cannot be manipulated directly. User 
Rolf 542 is in this moment being dragged in from a display region 550 with representations of known 
users and groups in order to be defined to have read privilege. As dragging is still in process, a 
condition that lasts for the order of magnitude of a second, user Rolf is not yet being displayed in the 

20 region 520 for effective access control settings. 

User Rolf 542, 552 has been dragged from a display region 550 with representations of known users 
and groups. This region 550 had been hidden until the operator has activated it through pressing a key 
combination (e.g. Ctrl-Shift-U). 

Figure 10 is out of a sequence of Figures that show a few steps in an implementation of the present 
25 invention. That sequence in order would be Figures 11, 12, 10, 13, 14. Another sequence which shows 
a few steps in the same implementation of the present invention is Figures 15, 16, 17, 18, 19, 20, 21, 
22, 23. These sequences are not shown proportionally in time, i.e. some of the steps shown here would 
be shown for a second only once an operator has become familiar with their dynamics, while some of 
the steps would be on the screen for extended periods of time. These intermediate steps are essential for 
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operator comprehension. The intermediate steps had to and will have to be designed with the same 
attention to detail as the more permanently displayed steps. 

The implementation shown in Figures 10 to 23 depicts the inventor's present preferred embodiment 
implementation and various improvements are desirable and may be expected. There are, however, 
5 important concepts being shown: How different display regions can show different transformations 
applied to the structured data which defines the access control settings for a resource; how display 
regions can be hidden and brought back; the convenience of having access control integrated with 
document display and with browsing; picture ids; and drag and drop. 

As used in connection with the present invention, the term "transformation" is to be understood in the 
10 following context: If there is a set of users Joe, Bob and Dan, then references to them might be stored 
in an array, e.g. [Joe, Bob, Dan]. The index of Joe would be 0, of Bob would be 1, of Dan would be 2. 
In the display region some representation would be shown for each user. The coordinates x,y might be 
for Joe 5,25, for Bob 105,25 and for Dan 205,25. This represents one simple transformation. 

Transformations may not only include numeric transformations, but also can include e.g. lookup of an 
15 image in a database, using a string user id as key, and subsequent image manipulation, i.e. 
transformation from string "Joe" to a cropped bitmap of his photo ID. 

One example simple algorithm to determine the coordinates to display each user could first sort, e.g. by 
static information such as name, employee id or by dynamic information such as most recent access to 
a document, then position first user in upper left corner, subsequent users to the right of previous user, 
20 optionally using constant space per user or as much space as needed to display variable size items such 
as name, and if positioning to the right causes overflow to the right then wrap around to start another 
row below. 

Transformation is from one mathematical or otherwise theoretical space into another. Many different 
algorithms may be used within the knowledge of one of ordinary skill in the art. 

25 It should be understood that the present invention is applicable in a broad variety of uses. In a more 
limited scenario, when there is little need to make changes, but mostly need to review access, then 
employing some techniques of the present invention still would be advantageous, but then studying 
these two sequences of Figures would not be as valuable as if someone wanted to employ all 
techniques of the present invention. 
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The implementation shown in Figures 10 to 23 may be using some older terms which are a little bit 
different from the rest of this disclosure. In case of conflict, the terms used in this disclosure are 
considered the preferred terms. 

Purpose of example sequences: After authoring documents in directory "graphicsexamples" the 
5 operator, Lee, wants to give user Rolf read privilege for all of directory "graphicsexamples" and to 
give group Marketing read privilege for directory "documents" only. 

First example sequence, giving a user read privilege for a directory: Figure 1 1 shows the result of 
nagivating to "graphicsexamples", e.g. by clicking on its icon in the tree on the left. Figure 12 shows 
the effect of clicking on the "resource entry" check box, i.e. in addition to unmodifiable "effective" 

10 settings also show "immediate" settings within the "entry". Figure 10, out of numbering sequence, 
shows after pressing a key combination a display region with representations of known users and 
groups, from which user Rolf is being dragged onto "immediate" settings. Figure 13 shows the effect 
on "immediate" settings, and on "effective" settings. Figure 14 shows after the known users and groups 
have been hidden already it is possible to completely go back to the original display layout, by hiding 

15 the "entry", with the "immediate" settings, by clicking on the "resource entry" check box. 

Giving a group read privilege would be as easy as giving an individual user read privilege. To illustrate 
something more complex, however, here we assume the operator wants to give group Marketing read 
privilege for one specific subdirectory only. 

Second example sequence, giving a group read privilege for a subdirectory only: Figure 15 shows the 
20 result of navigating to "documents", e.g. by clicking on its icon 508 in the tree on the left. Figure 16 
shows the effect of clicking on the "resource entry" check box. Figure 17 shows by context sensitive 
popup menu 560 creating a new "resource entry", linked as if there were "default inheritance". Figure 
18 shows the effects on "immediate" 545 settings and on additional links (labeled "additlinks") 546, 
within the "entry" 540. Figure 19 shows after pressing a key combination a display region 550 with 
25 representations of known users and groups, from which group Marketing is being dragged onto 

"immediate" settings. Figure 20 shows the effect on "immediate" settings, and on "effective" settings. 
Figure 21 shows after the known users and groups have been hidden already it is possible to completely 
go back to the original display layout, by hiding the "entry", with the "immediate" settings and the 
additional links, by clicking on the "resource entry" check box. Figure 22 shows it is possible to show 
30 "individuals" 525, in addition to "effective" settings, by clicking on the appropriately named 
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"individual users" check box. Figure 23 shows another practical display layout chosen, having 
transitioned from Figure 22 by context sensitive popup menu. 

Figure 24 shows from an early implementation of the present invention an example illustration of how 
composition of access control settings works. Since the making of that illustration more effort has been 
5 put into showing more information more comprehensibly in less space, but this illustration still serves 
as an example of what is covered by the expression "graphical representations of the results of 
transformations applied to the structured data which defines the access control settings for the 
resource", which is being used in this disclosure. 

The present invention provides a graphical user interface for representing and manipulating access 
10 control settings for a resource. 

The present invention departs from prior art in that a set of display regions for graphical representations 
of the results of transformations applied to the structured data which defines the access control settings 
for the resource appear integrated with a familiar display region for a representation of the resource, 
e.g. with the main view in word processing software, or with the main view in Web browser software. 

15 A number of functions should be implemented which modify the layout of the display regions, e.g. 

horizontal or vertical, or different relative or absolute sizes, and those functions should be available for 
invocation by the operator, e.g. through mouse gestures, or through key combinations. Also, functions 
may be implemented which modify the number of the display regions, i.e. add or remove some, and 
those functions should be available for invocation by the operator, e.g. through mouse gestures, or 

20 through key combinations. Further, a number of functions should be implemented which modify the 
transformations, either slightly, by modifying transformation parameters, or fundamentally, by 
switching algorithms, or in other ways, and those functions should be available for invocation by the 
operator, e.g. through mouse gestures, through key combinations, through menu choices, or through 
dialog boxes. 

25 It is assumed that standard object oriented mechanisms are put into place to automatically effect 
display of corresponding access control settings when a different resource is being displayed, e.g. 
because the operator has followed a link or has navigated in some other way. 

Because of the desire and need to keep display regions small, active regions for mouse gestures not 
necessarily have to be visually marked at all times. Visual feedback may be given by a changing 
30 cursor, or when a modification key is being pressed, e.g. the Alt-key. 



specification 



page 23 



10/802,658 



The identity transformation is a transformation too. One of the most useful transformations might be 
groups and users flattened to users only. Other possible transformations include: Aggregation of users 
into groups, sorting by name, or by affiliation. 

Certain combinations of modifying the layout of display regions and modifying the number of display 
5 regions might be more commonly described as "folding away" an extra display region. 

GUI Photo Ids 

The present invention further, and most visually striking in the context of access control, can 
graphically represent users by displays that comprise a photographic likeness of the user. Each 
photographic likeness should be processed by a method which, depending on quality desired to achieve 

10 and depending on computation effort willing to expend, comprises one or several of the steps of: (1) 
adjusting image color saturation toward a predetermined target saturation level; (2) converting to 
grayscale; (3) adjusting image brightness toward a predetermined target brightness level; (4) adjusting 
image contrast toward a predetermined target contrast level; (5) adjusting image sharpness toward a 
predetermined target sharpness level; and (6) masking with a shape such as an oval or an outline of a 

15 bust, the steps to be taken in an order that depends on which of these steps. A number of functions 
should be implemented which for an individual user result in different graphical representations, e.g. 
photo id, business card, icon, or name plate, and those functions should be available for selection by the 
operator, e.g. through menu choices or through dialog boxes, for immediate and subsequent use. 

Figure 25 shows different graphical representations for users and groups. Figure 26 shows use of id 
20 card representations, which is in contrast to Figure 9 using much smaller representations. 

The goal of processing the photographic likenesses is that graphical representations of collections 
comprising users appear more evenly patterned. It is not intended to achieve perfection. It is not 
intended to correct extremely bad images. 

Available prior art literature describes how to manipulate color saturation, brightness, contrast, and 
25 sharpness, and common software tools, such as Adobe PhotoShop may be employed. 

Popular photo editing software allows such manipulation if the operator pulls a slider element in the 
photo editing software's graphical user interface. The intention of the present invention is to 
automatically apply approximate adjustments to photographic likenesses for the purpose of making 
displays of collections of such likenesses appear more evenly patterned. 
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Photo editing software products have auto-adjustment options, but those options are designed to 
enhance individual images, which is not the same as the present invention, which aims to make images 
more similar. 

Adjusting image color saturation toward a predetermined target saturation level would preferably be 
5 used for reducing toward a predetermined low level. 

The ultimate reduction of color saturation is conversion to grayscale, which requires less computation. 

One implementation of conversion to grayscale comprises the steps of: If in RGB (the red, green, and 
blue color space) then setting all image elements' RGB components to the average of the weighed RGB 
components, (R*30+G*59+B*l 1)/100, else if in HSB (the hue, saturation, and brightness color space) 
10 then setting all image elements' S component to zero. Other formulae are known as well. 

Advantages of grayscale include: Less distraction by colorful attire, less potential for prejudgment by 
skin color. If using grayscale, then colors can be used exclusively to convey meaning in the user 
interface of the present invention, e.g. green for write privilege granted, red for privilege denied, blue 
for overflow. 

15 One implementation of adjusting image color saturation comprises the steps of: Converting RGB to 
HSB, adjusting S, converting HSB to RGB. 

One implementation of adjusting image color saturation toward a predetermined target saturation level 
comprises the step of: In HSB trimming all image elements' S component if it exceeds the target 
saturation level. This technique produces acceptable results for reduction toward a low level. 

20 Another implementation of adjusting image color saturation toward a predetermined target saturation 
level comprises the steps of: Obtaining a quotient by dividing the target saturation level by the largest 
possible saturation level, in HSB multiplying all image elements' S component with the quotient. This 
technique produces good results for reduction toward a low level. 

Another possibility for adjusting image color saturation toward a predetermined target saturation level 
25 involves histogram adjustments for saturation levels, eliminating peaks, reducing average, only if 
above target. 

One implementation of adjusting image brightness toward a predetermined target brightness level 
comprises the steps of: Determining the average of brightness for the complete region of an image, 
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obtaining a quotient by dividing the target brightness level by the determined average, if in RGB then 
multiplying all image elements' RGB components with the quotient and trimming any excessive 
products, else if in HSB then multiplying all image elements' B component with the quotient and 
trimming any excessive products. 

5 One implementation of adjusting image contrast toward a predetermined target contrast level comprises 
the steps of: Determining the arithmetic mean of brightness for the complete region of an image, 
determining an average deviation of brightness by averaging the absolute values of deviation of 
brightness from the determined arithmetic mean, obtaining a quotient by dividing the target contrast 
level by the determined average deviation, multiplying all image elements' deviation of brightness with 
10 the quotient and trimming any excessive results. 

GUI Each User 

A specifically useful configuration of the present invention is when the set of display regions 
simultaneously comprises the following two display regions: One display region for a graphical 
representation of a set of groups and users and their respective access privileges as defined by existing 
15 structured data for the resource, as well as another display region for a graphical representation of the 
result of transforming the set of groups and users and their respective access privileges into a 
corresponding set of individual users only and their respective effective access privileges. 

Seeing both helps understand, e.g. if defined user Lee write, group Marketing read, and user Rolf read, 
the corresponding set of individual users could be user Lee write, user Hank read, user Thomas read, 
20 user Christoph read, user Rolf read. 

There are at least two reasons for displaying the definition by group at the same time as displaying each 
individual user: (1) Manipulation would be via the defining region, e.g. adding user Rolf, or maybe 
obviously, removing group Marketing. (2) If a group changes, grows or shrinks, such change should 
correctly be reflected in the display of individual users. 

25 Individual operators should be able to set preferences. Such operator preferences could be system wide, 
per resource, or per hierarchical context. Of specific interest would be preferences that balance amount 
of information against display space used. Because of the declared goal of achieving highest rates of 
correct decisions by operators in the shortest possible time and while expending their least effort it is 
desirable to implement quite a number of operator preferences, including but not limited to sorting by 
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name, by group membership, by access time, by operator chosen deliberate order, by seating order, also 
id size, id type, relative locations of display regions, etc, whatever is necessary to make each individual 
operator work best and most reliably. It may be desirable to implement mechanisms that allow an 
administrator to preset, and also to override individual operator preferences. 

5 GUI Drag And Drop 

To enable the operator to modify access control settings for the resource, the invention should further 
comprise a display region for a graphical representation of at least one set of known users and groups, 
and the operator should be able to point to indicia for such known users and groups and drag such 
indicia into another display region to effect change to the structured data which defines the access 
10 control settings for the resource. To avoid display clutter, and to save display space, that display region 
for known users and groups unless activated by the operator, e.g. through a mouse gesture or through a 
key combination, should use an alternate layout that requires little space, e.g. nothing but a small 
indicator. 

To give someone access to a resource hence has become as easy as dragging and dropping that person's 
15 photographic likeness, and if implemented with all features of the present invention then there is 

immediate feedback that the person effectively is allowed to access and also later then when the person 
indeed does access the resource. 

Figures 27, 28, 29 show different options for arranging representations of known users, groups, and 
macros. Figure 27 shows a list, Figure 28 shows a hierarchy, Figure 29 shows custom grouping. 

20 One set to drag from could list all known groups and users. Alternative sets to drag from could list 
subsets, e.g. grouped by organizational affiliation, those who have been selected recently, those found 
by a resource specific and operator specific kind of association that can be formulated in an algorithm, 
or those who are in the personal address book of the only user who has write privilege if and only if the 
operator is that user. 

25 One skilled in the art can implement drag and drop using available functions of the graphical user 
interface object platform that is being employed. 

Specific value lies in the fact that by the principles of the present invention most access control related 
display regions do not appear in front of, cover up, or block the view of the familiar display region for 
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the representation of the resource itself, e.g. while editing a word processing document one would at 
any time be able to glance at a compact representation of its access control settings. 

Specific value lies in the fact that by the principles of the present invention the access control related 
display regions could and should be in the same relative position, often adjoining, to the familiar 
5 display region for the representation of the resource for virtually every resource in a system. 

GUI Comprehensive Log 

The present invention also can provide a graphical user interface for representing access log 
information and access control settings for a resource, wherein at least one display region contains a 
graphical representation of a set of individual users in which each of the individual users is graphically 

10 represented by a display which comprises: (1) the identity of the individual user, who unless indicated 
otherwise has read privilege for the resource; (2) indication whether the user has write privilege for the 
resource; (3) the time of the most recent read access by the user to the resource; (4) the time of the most 
recent write access by the user to the resource; (5) indication whether the most recent write access by 
the user to the resource has been the most recent write access by any user to the resource; (6) indication 

15 whether the most recent read access by the user to the resource has been before the most recent write 
access by any user to the resource; (7) indication whether the most recent read access by the user to the 
resource has been since the most recent write access by any user to the resource; and (8) indication 
whether the user currently is without read privilege for the resource. 

A specifically useful configuration is when the set of individual users consists of (1) the set of users 
20 who have any access privilege at all for the resource, and (2) the set of users who have accessed the 
resource in the past although they currently are without any access privilege for the resource. Ideally 
this user interface appears integrated with a familiar display region for a representation of the resource, 
e.g. with the main view in word processing software, in drawing software, or in other office or 
productivity software which would be used in a collaborative manner, or with the main view in Web 
25 browser software. See above for description of Figure 9. 

An implementation could use a table, one row per user, columns for items of information. A table is 
still a table even if there are no visible separating lines. A table is still a table even if there are no 
visible headers. 



specification 



page 28 



10/802,658 



Data could be shown "if so" and "if any", but "if not so" and "if not any" then a blank could be shown. 
Blank is a representation too, if defined, if in a predefined place, relative to more descriptive, more 
visible items. 

Entries could be sorted by time of access, by privilege, by user, by user affiliation, by a predetermined 
5 function, or in other ways. 

Time of access is meant to describe time of day and which day. If there has been no read or write 
access yet then don't display any value in its place. In addition, other parameters, including location of 
access, device used for access, bandwidth of access, form of access (e.g., text, graphic, video, 
translations, and other forms derived from a canonical document form by translation, transformation, 
10 sampling, etc.) and the like may be logged and displayed. 

More detailed information could be made available when the operator selects an entry or an item. 

In logging or in log processing it would make sense to pull together read accesses by one user which 
are not interspersed by write accesses by anyone. That could be displayed by first, last, or with details, 
either indicating number of repeated reads, or listing each read. 

15 An implementation could allow the setting of preferences that govern how accesses are put together, 
and how they are displayed in a compact way until or unless the operator interacts with the user 
interface to see more detail. Example scenarios include: The operator might want to know whether a 
user has read a resource an excessive number of times. E.g. if it is a paid service, or a resource 
intensive service. Maybe the operator by default only wants to know when user has read a resource the 

20 first time? E.g. if it has been a request to deliver a product, or to perform a task. Different applications, 
different preferences. 

The present invention has been motivated, in part, by wanting to know who has read a document before 
going into a meeting. 

An "indication" could be an icon, background color, foreground color, text color, or font variation. 

25 In the design of computer user interface, representations of a point in time commonly include an 
expression of relative time (e.g. "yesterday" or "2 hours ago"). 

One possible reasonable simplification can be to that a logged write access implies a read access. 
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An implementation could use a seating order or other physical location map based view instead of a 
table view. If well integrated with other sections of this disclosure, the operator could click on 
individuals to enable or disable writing or reading. 

A specifically useful configuration of the present invention is when the set of display regions 
5 simultaneously comprises: (1) A familiar display region for a representation of the resource, e.g. the 
main view in word processing software, or the main view in Web browser software, (2) a display 
region for a graphical representation of the set of groups and users and their respective access 
privileges defined by existing structured data for the resource, i.e. for easy review and manipulation of 
the settings, (3) a display region representing access log information for the resource, i.e. to show who 
10 actually did or did not access the resource and when, and (4) a display region for known users and 
groups which remains hidden unless activated by the operator, i.e. to allow modification of access 
control settings for the resource by simply dragging indicia for known users and groups. See above for 
description of Figure 9. 

If well integrated in the surrounding operating environment, the operator could click to contact a person 
15 by sending an email, or a message, or linking to other software, e.g. to send a reminder to look at a 
document. 

In an implementation that builds upon Apache Web server software much of the information needed 
for this kind of log display could be retrieved from standard Apache log files. It is possible, however, to 
achieve specific performance goals by implementing appropriate logging hook functions in a custom 
20 Apache module writing into a database. 

GUI Differentiating Every Resource 

To aid the operator in reviewing and administrating a user's access in a collection of resources, e.g. in a 
hierarchy or in a set, the present invention can provide a graphical user interface for representing access 
privileges for the user for resources in the collection of resources, wherein at least one display region 

25 contains a navigable structured graphical representation of the collection of resources, e.g. a tree view 
or a table view, in which each one represented resource is graphically represented by a display which 
comprises identification of that one resource and which, by applying a predetermined algorithm, 
indicates the user's effective access privileges for that resource by variations in at least one appearance 
parameter such as (1) indicative icons, (2) color, (3) transparency, (4) height, (5) width, or (6) font 

30 parameters. 
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In the structured representation each one represented resource, without exception, should be selectable 
by the operator, regardless of any such variations in appearance. Dynamic graphical feedback for a 
resource selected by the operator should clearly indicate information including the identity of the 
selected resource, and dynamic graphical feedback for a resource approached for being selected by the 
5 operator should clearly indicate information including the identity of that resource too. The clarity 
achieved by such dynamic feedback should purposefully be independent of any possible lack of clarity 
affected by the variations in appearance. 

A specifically useful configuration of the present invention is when variations in appearance comprise a 
reduction in height for the resource if the user is without any access privilege for the resource, and 
10 dynamic graphical feedback achieves clarity by using regular height for indicating identity. 

This feature has been introduced to answer the question: Which resources can one specific user access? 
What is the complete answer to that question? This can be important to review e.g. an external 
collaborator's access to project information. Can that person access all necessary resources? Can that 
person access more resources than necessary? Is it easy to find out about and to switch on and off 
15 access to resources that are determined necessary or superfluous, given that person's intended status? 

This feature is useful if a user is limited to access to a small number of items on a server that is full of 
thousands of documents. 

Resources can be selected individually by the operator, e.g. by using arrow keys, or by pointer. There 
could be automatic zooming when hovering. A regular size representation of the selected resource 
20 could float, or the equivalent of tool tips could be used to identify a resource that has a tiny 
representation. 

This feature is useful if accessible items are regular size, not accessible items are small, even if they are 
below one pixel size, because they will be zoomed when selected. 

If the operator selects with arrow keys then the selection should pop up to regular size. Ideally, keys 
25 should behave almost or completely the same as in known tree views. 

Dynamic graphical feedback indicates the identity of any selection made or being considered for 
making. One example for "being considered for making" is when the pointer is above where the 
selection would have to be made if it were to be made. Feedback options include popping to return to 
regular size, faded becoming solid, or traditional highlighting options. 
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It is important to note that once selected a variety of functions should be made available, e.g. through 
menu choices, possibly a context sensitive popup menu. Functions should include reviewing and 
modifying access control settings for the selected resource, reviewing log information, and switching to 
a different view. 

5 One aspect of what is innovative about this feature is that the operator can view and work with access 
privileges for another user. Previous art may provide some related functionality, but not focused on the 
point of view of an individual other user. This feature intends that the operator retains identity, but can 
readily comprehend what another user has access to. 

Figure 35 shows a representation of a hierarchy of resources, a tree of directories and documents. For 
10 this example one can assume the operator is a super user and has access to all resources. 

Figure 36 shows a representation of the same hierarchy of resources, this time differentiating what 
documents another user has access to. Documents which the user has access to are represented in 
regular appearance, e.g. "wheels_tire.html", and "two_rims.jpg". Documents and directories to which 
the user has no access are represented faded. To aid common usage patterns, there are two levels of 
15 fading: Very faded for items to which the user simply has no access, e.g. "05", "17", "index.html", 
"new_engine.html", "index.html", "other", "20", and "07"; and less faded, i.e. somewhat more 
recognizable, for directories which are parents or ancestors of items to which the user does have access, 
e.g. "documents", "graphics_examples", "18", "06", "2002", "lee", and "/". 

Figure 37 is similar to Figure 36, except that there is reduction in height for items to which the user has 
20 no access. To aid common usage patterns, there are two levels of reduction in height: Extreme 

reduction for items to which the user simply has no access; and less reduction, i.e. somewhat more 
recognizable, for directories which are parents or ancestors of items to which the user does have access. 

Figure 38 shows document "two_rims.jpg" highlighted, as selected by the operator. 

Figure 39 shows document "new_engine.html" highlighted in a more recognizable appearance, as 
25 selected by the operator, e.g. from Figure 38 by pressing the Up-Arrow-key. 

When the operator can select a resource then there should be further user interface elements that allow 
invocation of functions for the selected resource, including but not only functions to review and change 
the access control settings for that resource. Hence, if deemed necessary, the operator should be able to 
limit or to expand access to resources for the user while browsing through these views. 
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That a resource can be selected should not limit the selection to be one resource at a time. It should be 
possible to make a larger selection by selecting one resource after another, possibly using platform 
specific standard modification keys, e.g. the Shift-key and the Ctrl-key. 

This feature for hierarchies would be useful with file systems, e.g. source code, or scientific work. This 
5 feature for sets would be useful with records in a database, e.g. medical records. 

This feature can be implemented to show a variety of information per resource, depending on the 
intended application, including whether user is allowed to access, whether and when user actually has 
accessed, why user is allowed to access, who else is allowed to access, or a representation of the 
resource being accessed. What is important is that the operator becomes aware of what the user can 
10 access. 

GUI Information Overflow 

Layout is important in theory and practice of the present invention. Operator comprehension, and 
consistency should be increased through consistent and clever layout of user interface elements. One 
potential problem could be circumstances when there are more items to display than would fit into 

15 predetermined display regions, e.g. when there are a large number of users who are allowed to read a 
document. A commonly employed technique is to use scroll bars. The potential for pervasiveness, for 
omnipresence, is an important part of the appeal of the present invention. Consequently, minimal use of 
display space is an essential virtue in practice of the present invention. That said, there are at least three 
problems with commonly known scroll bars: (1) Scroll bars use display space themselves. That may 

20 not be a problem for a single document window which covers most of the display device, but it 

becomes a problem when several small regions each would need scroll bars of their own. When scroll 
bars use in excess of e.g. fifty percent of available display space, then there is a problem. (2) Scroll bars 
can cause abrupt reformatting of contents. Once content has increased to the point that it requires scroll 
bars, the very appearance of scroll bars takes away some of the display region which previously had 

25 been available for contents. That can cause reformatting, i.e. contents to be laid out somewhat 

differently in the remaining display region. (3) Scroll bars have proven not to fit in with the visual 
appearance that has been achieved with implementations of the present invention. If operators pay less 
attention to access control settings because individual, auxiliary, user interface elements divert their 
attention, then those user interface elements should be considered a problem. Scroll bars are considered 
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integral part of most user interface object platforms, and, for reasons which to explore would exceed 
the scope of this disclosure, there is little variation being practiced by software that employs them. 

The present invention suggests, instead of employing scroll bars, to use a graphical user interface for 
representing a set of a variable number of items in limited display space which comprises (1) a visible 
5 region, (2) a virtual plane, and (3) a small number of overflow indicators, wherein each of the 

represented items is graphically represented by a predetermined display; each of the item displays is 
positioned in the virtual plane; the virtual plane, with the item displays in it, shows inside the visible 
region in such as way as one sheet of paper, with drawings on it, would show through a cutout in a 
larger sheet of paper in front of it; the overflow indicators are located inside the visible region; the 

10 overflow indicators are located near such edges of the visible region beyond which more of the item 
displays are out of sight; the number of overflow indicators is zero in case all of the item displays fit 
inside the visible region; a plurality of functions are implemented which change the position of the 
virtual plane relative to the visible region; a context dependent subset of the functions are available for 
selection by the operator for immediate and subsequent use; the visible region remains constant in size 

15 and shape, even when the number and locations of the overflow indicators are changing; and the 
overflow indicators are graphically represented by using modern features of graphics platforms, 
including but not limited to transparency and anti- aliasing. As one can conclude from the description, 
there is a smooth transition between the appearance of this user interface when all items fit and the 
appearance when there is overflow. 

20 In order to visually alert the operator to overflow, it is possible to keep item displays predominantly of 
low color saturation, and to use overflow indicators that are of distinctively higher color saturation. 

Also, the overflow indicators near an edge of the visible region could, by variations in their graphical 
appearance, convey some information about the number of item displays which are out of sight beyond 
that edge. 

25 Represented items, obviously in the context of this disclosure, could be entities that have access 
privileges for a resource. 

Figure 30 shows a representation of the members of group "Regulars Club". Figure 31 shows an 
alternative representation of the same group, which uses less display space. Figures 32, 33, 34 are 
similar to Figure 30, but in less vertical space. Figure 32 shows the same group with an overflow 
30 indicator at the bottom, Figure 33 with overflow indicators at the top and at the bottom, Figure 34 with 
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an overflow indicator at the top. The overflow indicators are semitransparent blue triangles. The 
number of triangles equals the number of members beyond the respective edge. 

A great example is when there is a large number of people who may read a document. 

One improvement over scrollbars is that scrollbars take away space. Maybe most notable is that 
5 scrollbars narrow the width of text and hence can cause new calculation of line breaks or other changes 
to positions of objects. 

One improvement over the mouse wheel icon is that the present invention indicates to the operator 
where additional information is to be found. 

The present invention guides the eye towards where additional information will appear when scrolling. 

10 Functions to change the position, i.e. "for scrolling", can be invoked by the operator, e.g. by mouse 
clicking in or near overflow indicators, hovering over or near overflow indicators, or by keystrokes. 

Context dependence of determining the subset of functions should practically effect that the operator 
cannot scroll beyond meaningful limits. 

Using color saturation as user interface design element is specifically attractive or useful in applications 
15 where fitting into the visible region is common, overflow is less common, but overflow must not be 
overlooked. One example would be if the operator must approve of the set of users who can read a 
document then it would be undesirable if the operator would overlook any user who is hidden because 
of overflow. The present invention would alert the operator. Through distinctively different color or 
higher saturation it draws attention to the fact that more information must be reviewed than what is 
20 visible without scrolling. 

Possible overflow indicators include: (1) Triangles, one wide for one item, two half width for two 
items, up to a maximum, which at least is dictated by display device resolution but should be set before 
that to avoid device dependent appearance; or (2) a textual representation of the number of hidden 
items, possibly within a bounding shape, e.g. a rectangle. 

25 Access Control Settings Macros 

When thoroughly implementing access control for resources one will encounter the concept of change 
in time. While it can be interesting to explore such a topic theoretically, here this disclosure resorts to 
using examples. If giving a group read privilege for a document, e.g. giving group "Staff 5 read 
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privilege for document "products.html", then the underlying model will permanently store the group id, 
e.g. "Staff, in access control settings defining structured data for the document. When at a future point 
in time a user requests read access then if at that time the user is a member of the group, e.g. "Staff, 
then access will be allowed. Newly joined members of the group, e.g. "Staff, will be allowed to read. 
5 This behavior may be expected, appropriate, and intended in many circumstances. There are other 
circumstances, however, when such behavior would be undesirable, and other behavior would be 
preferable. One example could be the summary of a meeting with another business entity, e.g. a 
document "proceedings. html", under the special circumstance that the meeting has been covered by a 
confidentiality agreement which requires individual personal physical signatures of all parties. 
10 Automatic read privilege for new members of "Staff would violate the confidentiality agreement, 
assuming it improbable that anyone remembers, or bothers to keep collecting signatures, if that even 
were permissible at such later time. 

It does not take a convoluted example. A simple policy could do. How to implement a policy that 
certain documents by default should only be accessible to those employees who have been a member of 

15 the organization on the day the document has been authored? An answer lies in not storing the group 
id, e.g. "Staff, in access control settings defining structured data for the document, but in storing each 
individual user id, whatever number there are. Does this mode replace or obsolete the use of groups? 
No. There is use both for groups in their known meaning, and for this new concept. Examples for 
documents that, by using groups, still should automatically become accessible to all new members of 

20 "Staff could include: Employee health plan brochures, company tradeshow schedules, etc. 

For greater efficiency in administrating access control settings, the present invention defines the 
concept of "access control settings macro" ("macro") for use within the context of the present 
invention. Whatever way a macro has been defined, e.g. as constant set of user ids, or as algorithmic 
function, and whatever way it is being identified, e.g. by id, or by icon, the essence of a macro is that 
25 when it is used in modifying access control settings then not the id of the macro will be stored in access 
control settings defining structured data for the resource, but some other information, consistent with 
whatever it has been defined to be, e.g. the constant set of user ids, or a set of user ids resulting from 
evaluating the function. 
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For the example group "Staff there might be an accompanying macro "Staff today", or "Staff now". 
The group will change in time, but where the macro has been used there the set of individual users has 
been defined the day, or moment it has been used. 

Another useful macro would be "those who have any access privilege at all, right now, for" a specific 
5 resource, or maybe equivalent "those who are, right now, allowed to read" a specific resource. 

Figure 28 shows three main branches in a hierarchy to choose from: Users, Groups, and at the very 
bottom, Macros. 

The theory of the present invention is equally applicable when not recognizable user ids, or group ids 
are being stored, but when equivalent, or similarly usable machine readable constructs are being used. 

10 Macros not only can be used in graphical user interfaces of the present invention, but they could be 
used in other user interfaces for access control settings as well. E.g. a command line interface could 
accept a macro as parameter, instead of a group, to add its users with read privilege for a resource. 

In other words, the present invention suggests a user interface for representing and manipulating access 
control settings for a resource, where in tradition the kinds of entities that can be defined to have and 

15 not to have various access privileges comprise users and groups, where instances of structured data 
comprising identifiers of such entities, i.e. user ids and group ids, are stored permanently as definitions 
of the access control settings, where macros can be defined to encompass sets of such entities, 
specifically sets of users, and where those macros can be used in user interface interactions analogously 
to the use of groups in those interactions, while only identifiers of the entities which constitute the 

20 macros are stored permanently in those instances of structured data, rather than identifiers of the 
macros themselves. 

Access Dependent Contents 

If the present invention enables people to control who can access what document, what will follow is a 
greater diversity in access control settings than in environments where access control is more difficult 
25 to manipulate. One consequence will be that hyperlinks have a much higher probability to lead a user to 
a document that the user is not authorized to access. Here are two examples: 

(1) A researcher may publish a table of contents for all work that researcher is doing. Some items may 
be limited to a certain audience. Will anyone see the restricted items in the table of contents? Should 
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there be separate tables of contents for different audiences? Should the researcher have to keep track of 
who may see which table of contents? 

(2) A report may have an introductory paragraph that identifies at which site samples have been 
collected, or how much is being paid for it, by reference to the document with which it has been 
5 ordered. That order document may be limited on a need to know basis, as should be the information 
extracted from it. 

The present invention suggests a significant improvement in dealing with these situations, by the use of 
markup which causes conditional omission of elements of documents, conditional on access control 
settings for resources, in general resources other than the document itself, resources which are 
10 identified by reference, mostly that would be resources which are referenced in the section of the 
document which is subject to conditional omission. 

For example (1) the present invention suggests each entry in the table of contents to be shown only on 
condition that the person viewing the table of contents is authorized to see the document that is referred 
to from the entry by hyperlink. 

15 For example (2) the present invention suggests use of markup to omit that paragraph from being shown 
to people who are not authorized to see the initial order document. 

The present invention suggests that optional attributes can be used in a descriptive way to effect 
visibility for elements in documents which automatically depends on the user's access privileges for 
other resources. 

20 More formally defined, the present invention suggests a system for omitting elements from documents 
as a function of user identity and access control settings which comprises a processing mechanism 
which processes documents before passing them on, a parsing mechanism in the processing mechanism 
which parses markup language for elements and attributes, and an access control function mechanism 
which is activated by the parsing mechanism when a defined access control function attribute, e.g. 

25 adc:onlyIf= M ../internal/customerlist.html", is encountered. The attribute should provide a value which 
identifies a resource, e.g. ../internal/customerlist.html. The access control function mechanism should 
make a determination of access privileges which the user has for that resource, and then should by 
applying its predetermined function to the access privileges make a decision on whether to omit the 
element, e.g. a <li>, a <p>, or a <span>, with which the attribute is associated, e.g. to omit if the user is 
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not allowed to read document ../internal/customerlist.html. That decision should be implemented by the 
processing mechanism, coordinately acting together with the other mechanisms. 

If such a system is implemented for server side processing, then processing should not modify the 
original documents. Any omissions are made instead in processed versions of the documents, i.e. in the 
5 documents that are being transferred to clients. A document that is stored on the server can appear at 
different levels of completeness to different users, depending on their respective access privileges for 
other resources, i.e. for the resources identified by the values of access control function attributes. 

An implementation for server side processing by an Apache module, custom programmed at the lowest 
level, e.g. in C, or at a higher level, e.g. in Java, should use the same or equivalent mechanisms to 
10 communicate with the control server as have been described for making the decision for actual access 
to resources. The module should give the control server (1) a user id, (2) a URI path, and (3) an access 
method, which most probably would be READ, the control server should return its determination of 
whether access is authorized, and then the module should apply its predetermined function to make a 
decision on whether to omit. 

15 In the context of this section of this disclosure, "the user" obviously is an "accessing user", but the 
mechanism described herein could be used to process for any user, e.g. to review what another user 
would see. 

It is not a requirement for a reference to be both in the section to be considered for omission and to be 
used in the condition for omission. It is expected that most use of this feature will be with the same 
20 reference both in the section considered for omission and in the condition, but it is not required. 

It would be a very useful feature for document editing software to have support built in to extract one 
or several references to resources from a selected section of a document and to automatically copy 
those references into a conditional construct for the present invention that covers that section of the 
document. 

25 It might be considered useful to implement support for an access control function attribute that during 
processing automatically extracts references from the contents of its element. E.g. 
adc:onlyIfRefs="true" (synonymous to adc:onlyIfAHRefs="true") or adc:onlyIfAnyRefs="true". One 
disadvantage, however, would be higher computational effort at each access. Another disadvantage 
would be the need to understand potential contents of elements. 
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As an example, Figure 40 shows underlying markup of a document. Figure 41 shows the document in a 
WYSIWYG editor, for its author. Figures 42 and 43 show the document as it consequentially is 
rendered differently for different users. 

As another example, Figure 44 shows underlying markup of a document that refers to images. Figure 
5 45 shows the document, including images, for its author. Figure 46 shows diverse access control 
settings of individual images. Figures 47 to 49 show the document as it consequentially is rendered 
differently for different users. 

Additional Elements 

Graphical user interfaces could directly communicate with the control server. The control server should 
10 be implemented not only to interface with the Web server, but also with graphical user interface 
components that implement the present invention. Coincidentally, the communication between the 
control server and GUI components on a client machine may be routed through the Web server, which 
can give the benefits of using an outside connection that is open already, and that might be encrypted 
already. 

15 The control server may greatly benefit from caching in memory. The control server may greatly benefit 
from caching more than one representation of the same data, for different kinds of queries which may 
come from GUI components. 

The control server may be able to communicate various kinds of information about access control. For 
example, a program might want to perform auditing of access control settings. The control server's two 
20 originally intended partners for communication, however, are the Web server and graphical user 
interface components. The purpose of the graphical user interface components is to review and to 
modify access control settings. 

One aspect of improving ease of use it to always have access control at hand, whenever working with 
resources or documents. If the client machine runs a Web browser, then one way to achieve apparent 
25 ubiquity is to put access control GUI components into a frame next to the documents being viewed. If 
the client machine runs an application, then omnipresence can be achieved by putting access control 
GUI components into larger displays together with browser views, and as needed optionally with trees 
views, or other views. In either scenario, events should be sent between individual components, using 
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techniques appropriate in the GUI component architecture which is in use, to ensure the access control 
display matches the current document display. 

In a well-designed user interface that implements the present invention it should be possible for the 
operator to follow a circle, or a mesh of navigation. From a resource one could explore to a user, from 
5 the user to other resources, from a resource to other resources, groups, logs, hierarchies, references, etc. 
If something is related, then it should be possible to navigate to it. All user interface components 
should be synchronized appropriately. 

Specific points of view which should be provided by a good implementation of the present invention 
include: (1) Given a user, a resource, and an access method, is it authorized or not? (2) Given a 
10 resource, which users are authorized to access with which methods? (3) Given a user, which resources 
is the user authorized to access with which methods? 

One can expect implementations where a user or a group is replaced by another concept, e.g. something 
like a role. The theory and principles of the present invention still would be applicable. 

Photographic likenesses might be replaced by drawings, or by other kinds of artifacts. The theory and 
15 principles of the present invention still would be applicable. 

Good implementations of the present invention should function well for communication among people 
whose native languages are different. Many of its features are language neutral, and GUI 
implementations should lend themselves well for different localizations (internationalization) 
nevertheless seamlessly accessing the same resources. 

20 This disclosure is not specific about who has rights to set rights. For easier understanding when reading 
this disclosure one may want to assume the operator is a super user. Another possible assumption is 
that the operator has the right to set rights on resources which the operator self owns, on documents 
which the operator self has authored. In implementation various algorithms may be used. 

Instead of READ and WRITE, HTTP uses GET and PUT. Other names may be used for equivalent 
25 concepts. 

One example why other than "allow" an implementation might want to support "deny" is the 
announcement of a surprise birthday party, which should be seen by everyone except the person to be 
surprised, hence e.g. "allow Department" and "deny Bob". 
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Multidimensional spaces may also be implemented in the present invention, to accommodate higher- 
dimensional user interface models and more complex access control models. Such user interface 
models, including cubic three dimensional web browsers, and temporally defined interfaces are known 
in the art, and any reference to dimensions or spaces herein should be understood to include such 
5 multidimensional spaces. In sensitive environments, for example, access to a given resource may be 
permitted only at certain times. In a records-retention system, for example, certain records may be 
encrypted with a key that requires access to a verified source of time information. After a 
predetermined time, e.g. seven years after resource creation or storage, the decryption would no longer 
function, effectively destroying the document by preventing access to the contents. In a similar way, 
1 0 documents which should not be available until a particular time may be encrypted to prevent access 
until the designated time. (Some refer to these complimentary functions of the system as "disappearing 
ink" and "appearing ink" functions.) Similarly, employees of a bank have access to the contents of the 
vault only at times designated by the time lock on the vault. 

Other information may be incorporated into the system of the present invention. For instance, multipart 
15 authentication, such as with biometric indicators, hardware keys, and the like may be directly 

interfaced to the methods presented herein. In this way, control of access to physical resources (rooms, 
facilities, etc.) may be managed using the graphical interface of the present invention. 

Using the present invention, it is feasible to design systems that feel like prior art messaging systems to 
users, but that actually store all messages on servers that use the present invention. In order to achieve 
20 high levels of security, all writing and reading will be done to and from a server that is secured by the 
present invention, optionally using prior art messaging systems only to carry concise notifications that 
new information is waiting for an addressee to read. 

In such a communication system, writing of messages is done when logged in, e.g. in a secure applet in 
a secure page in a browser. Reading can be done with traditional secure clients reading from the secure 
25 server. Messages are only available from the secure server with secure log in. Notably different than 
email, messages can be revoked, either completely or for a subset of users. Notifications over prior art 
messaging systems may be used to deliver a link to the secure message as resource. 

In such a communication system, optional interfaces to messaging systems of the prior art may allow 
sending and receiving of email, instant messages, and other messages. Such optionally supported 
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sending and receiving of legacy messages to and from individuals without full access to the 
communication system, however, in most cases would result in lower security. 

Using the present invention, it is feasible to design systems that use proxy technology to retrofit the 
present invention in front of existing servers. Specifically, Apache configured as proxy server and with 
5 the present invention can provide access control for existing resources. 

While the invention has been described in its preferred embodiments, it is to be understood that the 
words which have been used are words of description rather than of limitation and that changes may be 
made within the purview of the appended claims without departing from the true scope and spirit of the 
invention in its broader aspects. Rather, various modifications may be made in the details within the 

10 scope and range of equivalents of the claims and without departing from the spirit of the invention. The 
inventor further requires that the scope accorded his claims be in accordance with the broadest possible 
construction available under the law as it exists on the date of filing hereof (and of the application from 
which this application obtains priority), and that no narrowing of the scope of the appended claims be 
allowed due to subsequent changes in the law, as such a narrowing would constitute an ex post facto 

15 adjudication, and a taking without due process or just compensation. 
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